3 ms·
This is my understanding of the problem: when a Go program is initialized on 32-bit windows or linux systems, it tries to allocate 512MB of contiguous virtual r
by tashmahalic 15y ago
This is my understanding of the problem: when a Go program is initialized on 32-bit windows or linux systems, it tries to allocate 512MB of contiguous virtual ram. When the virtual address space is too fragmented, the initialization will fail and the Go program won't start. Is this correct?
We're considering using Go for an end-user desktop application for Mac, Windows, and Linux. Of course, we don't have control over whether our users have a 32-bit or 64-bit system. And, of course, our app has to work 100% of the time. What can we do to make Go work 100% of the time on these 32-bit systems?
- JoeAltmaier 15y agoDon't know what it means for the virtual address space to be fragmented. Each process begins with a pristine virtual address space.
- 4ad 15y agoMostly, but not really, apart from the binary image itself, its dependent shared libraries are also loaded, and the various images loaded might have virtual address space reservations marked in the header. In normal scenarios there should be enough contiguous address space, Go programs only link to ntdll.dll and winmm.dll. While it's true that on recent Windows versions these two shared objects pull around 30 other shared objects, all the DLLs shipped with Windows have a base address chosen so that they only take a very small chunk of address space and most address space is contiguous. 512MB of contiguous reservation shouldn't be a problem to get. The fact that this is not happening means that 3rd party DLLs are loaded, this happens if you use a program, knowingly or not, that install user mode hooks.