Abtin Forouzandeh
discovered a bug in the go implementation for a 32-bit Windows platform. The simplest program starts and then drops.
According to the results of the study of the error, it turned out that the matter of memory allocation is run go. In a 32-bit Windows system, a total of 4GB of virtual address space is available, the upper 2 of which are reserved for the system, and the process remains the lower 2 gigabytes. When you run the program on go compiled by the 8g runtime compiler, it tries to allocate 512 megabytes of virtual address space for the needs of the garbage collector. The problem is that the memory is required in one piece. However, in this implementation of the language, the KERNELBASE.DLL library is loaded in the middle of the address space, the system cannot allocate a lengthy piece of memory and a crash occurs.
The go developers are
notified of the problem, but the error is prioritized “Priority-Later” and is not fixed in go 1 version. Correction decisions are reduced to “Switch to 64 bits” and “Switch to Unix” and to the questions “How did we see this?”. The author of the original post preferred to switch from go to C.
UPD: As
atd correctly points
out even if you switch to 32bit Linux, problems with the garbage collector will not disappear.
This bug shows that for certain data structures the garbage collector does not cope with the task. For long-running and actively using memory programs, this means constant drops. Developers' recommendations are black magic of the type “Separate long-lived and short-lived data across different structures” or, again, “Switch to 64 bits.” In the near future, the error will not be corrected.