Do Not Use Go for 32bit Development

2012 April 08 10:48 AM

I’m sitting here rewriting a ton of Go code in C. And I can’t bill for the time. As the principle programmer, the buck stops here. I talked to my client and took responsibility. My mistake was trusting Go. I should have remembered my motto, stolen from the Royal Society: nullius in verba.

Despite the 1.0 release announcement of Go, I must emphatically state that if 32bit support is a hard requirement for your development, Go is not a viable option.

There are a number of bugs in 32bit Go, but the real show stopper is this:

At runtime init, Go programs attempt to reserve 512mb of virtual address space. If they can’t do this, they crash. Go needs the space because it is garbage collected - presumably, all GC languages, or any program that takes a similar approach to memory management, will be susceptible to the same problem. On 32bit Windows machines, processes only have access to 2GB user space memory. This user space can become fragmented (say, a linked DLL is loaded by the system before the 512mb allocation occurs), preventing the Go runtime from reserving its arena.

Go expects one large allocated block. I assume that other GC runtimes implement an algorithm to deal with this problem by requesting smaller chunks of memory.

The problem is hard to replicate and test - most of the time, Go programs run perfectly fine. I speculate that rebooting the machine might help solve the problem. I also speculate that only Windows is susceptible - I’ve had no bug reports about the linux version of my code. The Go devs are aware of the issue, but have designated it as low priority.

I love programming in Go. And I agree with Rob Pike that programmers complain too much when they should be fixing the problem instead. Unfortunately, I am not familiar enough with the Go runtime code to dive and make the required changes with confidence that I have both actually fixed the problem and not introduced bugs into the memory management code. I don’t have time before my deadline to look into the issue either. I will certainly look into fixing the problem once I have some spare time.

Edit: I would like to point out that the Go devs have been very helpful in diagnosing the issue. Unfortunately, their resolution always boils down to “Switch to 64bit”.

Edit: The original article states that Go tries to reserve 512mb of RAM. This is incorrect: it tries to reserve 512mb of virtual address space.

Edit: More comments on hacker news

blog comments powered by Disqus