mirror of
https://github.com/golang/go
synced 2024-11-12 09:20:22 -07:00
runtime: fix memory allocation on 386
BSD and Darwin require an extra page between end and the first mapping, and Windows has various memory in the way too. Fixes #1464. R=r, r2 CC=golang-dev https://golang.org/cl/4167041
This commit is contained in:
parent
5b1b2ba9c7
commit
1cc8c87dc1
@ -286,10 +286,16 @@ runtime·mallocinit(void)
|
||||
// of address space, which is probably too much in a 32-bit world.
|
||||
bitmap_size = MaxArena32 / (sizeof(void*)*8/4);
|
||||
arena_size = 512<<20;
|
||||
|
||||
p = (void*)(((uintptr)end + 64*1024 - 1) & ~(64*1024-1));
|
||||
if(runtime·SysReserve(p, bitmap_size + arena_size) != p)
|
||||
runtime·throw("runtime: cannot reserve memory bitmap virtual address space");
|
||||
|
||||
// SysReserve treats the address we ask for, end, as a hint,
|
||||
// not as an absolute requirement. If we ask for the end
|
||||
// of the data segment but the operating system requires
|
||||
// a little more space before we can start allocating, it will
|
||||
// give out a slightly higher pointer. That's fine.
|
||||
// Run with what we get back.
|
||||
p = runtime·SysReserve(end, bitmap_size + arena_size);
|
||||
if(p == nil)
|
||||
runtime·throw("runtime: cannot reserve arena virtual address space");
|
||||
}
|
||||
runtime·mheap.bitmap = p;
|
||||
runtime·mheap.arena_start = p + bitmap_size;
|
||||
|
Loading…
Reference in New Issue
Block a user