3 ms·
Looking through the linked bug and the testing they did, the issue doesn't appear to be using Go for 32 bit systems. It's using 32 bit compiled Go programs tha
by ismarc 15y ago
Looking through the linked bug and the testing they did, the issue doesn't appear to be using Go for 32 bit systems. It's using 32 bit compiled Go programs that use cgo on 64 bit Windows systems.
Understanding the why of the issue is extremely important in this case. Based on the discussion in the bug report, I would expect that using the 32 bit compiler for 32 bit architectures and 64 bit for 64 bit architectures would not result in the issue occurring. Before abandoning Go, I would very much identify that this is indeed the case. With Go's young age, I would very much use the architecture specific compilers for the specific targets which is different than normal expectations, but not at all unreasonable.
- abtinf 15y agoUnfortunately, this is not the case. 32bit compiled runs great on 64bit machines, where it gets the full 4gb of space and memory fragmentation at init is very unlikely to be a problem. Edit: similarly, 64bit also is immune because of how the main platforms allocate virtual address space to clients.
- ismarc 15y agoHrm, that actually makes the issue tricky to solve. I don't have any Windows machines to work with, so I can't test, and I'm not very familiar with using Go on Windows in general, but is it possible to specify delayed load of the DLLs? That should allow the main Go system to get fully initialized (and allocate the chunk of memory it needs) before loading the DLLs needed for the cgo portions.
- 4ad 15y agoNobody is using cgo, it's the system DLLs which get loaded in the middle of the address space. This is very very unusual, Windows tries hard to avoid such things. It could be solved by making the initial virtual address space reservation in the PE header, not requesting it in the initialization path, that would always work, even with cgo.
- sausagefeet 15y agoI don't believe this is true since the issue is that the GC is conservative so on a 32 bit system integers look a lot like pointers, so the GC won't free them.
- dchest 15y agoDid you read the post?
- sausagefeet 15y agoNope, my bad. This is the 2nd or third post on Go not being any good on 32 bit environments in as many days. The other post I read is what my post is in reference to.