1
0
mirror of https://github.com/golang/go synced 2024-11-12 10:00:25 -07:00

runtime: pass correct size to malloc

In both cases we lie to malloc about the actual size that we need.
In panic we ask for less memory than we are going to use.
In slice we ask for more memory than we are going to use
(potentially asking for a fractional number of elements).
This breaks the new GC.

LGTM=khr
R=golang-codereviews, dave, khr
CC=golang-codereviews, rsc
https://golang.org/cl/116940043
This commit is contained in:
Dmitriy Vyukov 2014-07-22 01:56:19 +04:00
parent 92c54e4a73
commit 7bcbdbd904
2 changed files with 6 additions and 2 deletions

View File

@ -41,7 +41,7 @@ newdefer(int32 siz)
}
if(d == nil) {
// deferpool is empty or just a big defer
total = TOTALSIZE(siz);
total = runtime·roundupsize(TOTALSIZE(siz));
d = runtime·malloc(total);
}
d->siz = siz;

View File

@ -117,14 +117,18 @@ growslice1(SliceType *t, Slice x, intgo newcap, Slice *ret)
if(newcap1 > MaxMem/typ->size)
runtime·panicstring("growslice: cap out of range");
// Try to use all memory that malloc will give us...
capmem = runtime·roundupsize(newcap1*typ->size);
// ...but don't ask for fractional number of elements (that can confuse GC).
newcap1 = capmem/typ->size;
capmem = newcap1*typ->size;
flag = 0;
// Can't use FlagNoZero w/o FlagNoScan, because otherwise GC can scan unitialized memory.
if(typ->kind&KindNoPointers)
flag = FlagNoScan|FlagNoZero;
ret->array = runtime·mallocgc(capmem, (uintptr)typ|TypeInfo_Array, flag);
ret->len = x.len;
ret->cap = capmem/typ->size;
ret->cap = newcap1;
lenmem = x.len*typ->size;
runtime·memmove(ret->array, x.array, lenmem);
if(typ->kind&KindNoPointers)