Commit 5572fc4
committed
runtime: reserve 16GB of heap address space on 64-bit unix
allocateHeap capped the heap at 1GB for all targets, so with -gc=conservative
or -gc=precise any single allocation approaching 1GB (for example a scrypt
key-derivation buffer with N=1<<20, r=8) failed with out of memory regardless
of available system RAM.
Reserve 16GB of virtual address space on 64-bit targets instead. The mmap is a
reservation, not a commitment: pages cost physical memory only when first
touched, and the existing halve-on-failure loop still adapts when the map is
refused. 32-bit targets keep the 1GB cap; the size is derived from TargetBits as a
shifted constant, since a plain 16GB literal does not compile on 32-bit
targets even in a dead branch. This is the direction the growHeap
comment already points at: "If we run out of memory, we should consider
increasing heapMaxSize on 64-bit systems."
With this, the practical limit under the blocks GC on 64-bit hosts becomes
actual system memory, matching the boehm default and big Go; true exhaustion
surfaces as the OS's memory pressure handling rather than a fatal error at an
arbitrary 1GB.1 parent bdc4a21 commit 5572fc4
1 file changed
Lines changed: 12 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
318 | 318 | | |
319 | 319 | | |
320 | 320 | | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
| 331 | + | |
321 | 332 | | |
322 | 333 | | |
323 | 334 | | |
324 | 335 | | |
325 | 336 | | |
326 | 337 | | |
327 | | - | |
| 338 | + | |
328 | 339 | | |
329 | 340 | | |
330 | 341 | | |
| |||
0 commit comments