Go: Severe memory problems on 32bit Linux
groups.google.com
Go: Severe memory problems on 32bit Linux
1–10 of 159 posts
Re: Go: Severe memory problems on 32bit Linux
#2Wow. That third message, with suggestions for avoiding the bug, reads like a twisted joke. Highlights:
"avoid struct types which contain both integer and pointer fields"
"avoid data structures which form densely interconnected graphs at run-time"
"avoid integer values which may alias at run-time to an address; make sure most integer values are fairly low (such as: below 10000)"
I understand that this isn't a completely brain-dead garbage collector, but warnings like that really scream "I'm just a toy language". It doesn't seem wise to call such a fragile programming tool production-ready or 1.0; the 32-bit implementation should be tagged as experimental, if only to lessen the damage to Go's reputation.
Re: Go: Severe memory problems on 32bit Linux
#3This is the relevant bug: http://code.google.com/p/go/issues/detail?id=909
As the discussion there and in the thread says, the root problem is that Go uses a conservative garbage collector, and on 32-bit a lot more values look like pointers than on 64-bit, so many more things don't get freed in long-running processes. Seems not to be easy to fix.
Re: Go: Severe memory problems on 32bit Linux
#4to go back to 32 bit hardware, you will be running very old machines that you can buy off ebay for <200$ and the power cost offset the new hardware cost in several months.
Re: Go: Severe memory problems on 32bit Linux
#5to go back to 32 bit hardware, you will be running very old machines that you can buy off ebay for <200$ and the power cost offset the new hardware cost in several months.
Running a 32-bit operating system on 64-bit hardware is still pretty common. And this problem afflicts ARM as well.
Re: Go: Severe memory problems on 32bit Linux
#6to go back to 32 bit hardware, you will be running very old machines that you can buy off ebay for <200$ and the power cost offset the new hardware cost in several months.
Running a 32-bit operating system on 64-bit hardware is still pretty common. And this problem afflicts ARM as well.
This is really disappointing. I was hoping to do some stuff with Go on ARM, but it looks like they are not too concerned about this bug.
Re: Go: Severe memory problems on 32bit Linux
#7to go back to 32 bit hardware, you will be running very old machines that you can buy off ebay for <200$ and the power cost offset the new hardware cost in several months.
I would run a 32-bit OS (even if the hardware supported 64-bit) if I wanted to squeeze every last bit of usable memory out of a VPS.
Re: Go: Severe memory problems on 32bit Linux
#8This is the relevant bug: http://code.google.com/p/go/issues/detail?id=909 As the discussion there and in the thread says, the root problem is that Go uses a conservative garbage collector, and on 32-bit a lot more values look like pointers than on 64-bit, so many more things don't get freed in long-running processes. Seems not to be easy to fix.
Publicizing the bug may speed the fix along. Here's the real test: is hitting the front page of HN going to make a difference?
Re: Go: Severe memory problems on 32bit Linux
#9to go back to 32 bit hardware, you will be running very old machines that you can buy off ebay for <200$ and the power cost offset the new hardware cost in several months.
I addition to arm and 32bit OSs, you're going to run into a lot of 32 bit hardware if you try to distribute a program written in Go to the masses (or at all really). I'm using some now.
Re: Go: Severe memory problems on 32bit Linux
#10This is the relevant bug: http://code.google.com/p/go/issues/detail?id=909 As the discussion there and in the thread says, the root problem is that Go uses a conservative garbage collector, and on 32-bit a lot more values look like pointers than on 64-bit, so many more things don't get freed in long-running processes. Seems not to be easy to fix.
Publicizing the bug may speed the fix along. Here's the real test: is hitting the front page of HN going to make a difference?
I don't think this one is lacking interest, but an obvious fix. It looks like Russ Cox did commit a fix for some portion of the cases. But a better fix would either need to significantly modify the way things are laid out to reduce the odds of false positives, or else move to a precise GC.
(Precise GCs are possible in C-like languages, but trickier to implement. Here's a recent paper on one: http://www.cs.utah.edu/~regehr/papers/ismm15-rafkind.pdf)