Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
What version of Go are you using (
I think this qualifies as a bug. Succinctly put: on 32-bit linux,
My question is mainly directly towards @aclements in regards to his code comment:
If I can get an answer to that, I am happy to open a CL that closes this issue.
Sorry, I'd missed this.
I think my comment was saying that it could literally just reserve less space for the heap arenas, and fall back to using fresh mmaps when
Right now, 32-bit reserves address space for all possible arenas just to avoid interleaving the memory reservations with the heap, since that would cause memory fragmentation and make it more likely that a large allocation would fail. But on 64-bit, we don't reserve any space up front for the arenas and instead just mmap them as we need them.
It's probably a good idea to still reserve some space on 32-bit for the area metadata, but it could probably be much less. We could also try to generate hint addresses that make it less likely that the heap and the heapArenas will collide. For example, we could continue to make space for all heapArenas before the initial heap hint, but just not reserve that space. Even without the reservation, the heap is likely to grow up from the hint and not interfere with the heapArenas space unless we're really tight on address space.