<p dir="auto">It's been brought up on the mailing list (citation needed) that some people want to run Go with heaps beyond the default limit (128 GB today).</p>
<p dir="auto">Perhaps we should revise the limit at each Go release according to some metric. One possible metric would be to make sure that Go can address all the memory available on the largest VM you can rent from Amazon or from Google.</p>
<p dir="auto">In Go 1.4, the compiler still has a hardcoded 128GB memory limit. While this is much better than the 16GB limit from 1.0, it's presenting a real limitation to using Go for big-data scientific work, such as my research, such as <a href="https://github.com/ndaniels/cablastp2">https://github.com/ndaniels/cablastp2</a>. While it's trivial for me to change the allocation limit in go's source and rebuild my own compiler, this presents a problem for other users using my work; if they find out that they need to patch the Go compiler just to build my source code, they're not going to like it. It's already enough of a barrier for some users to require they have the Go compiler. While I could provide statically compiled binaries for a variety of platforms, I can't target every OS and kernel version, and it becomes a nuisance to update those binaries whenever I update my source code.</p>
<p dir="auto">I understand Go's memory allocation philosophy, and I realize that (for the time being) it needs to be hardcoded in a Go binary. But, it would be a huge improvement if a compiler flag could be used to alter the allocation limit for a particular package being compiled. Even better would be a runtime flag (much like Java's Xmx flag for the heap).</p>