The problem itself seems quite serious and I would seriously reconsider using Go if I was interested in it in the first place, but after seeing the way this is treated by the Go "community", I am pretty sure I will never ever even think about using Go for anything.
Go: Severe memory problems on 32bit Linux
51–60 of 159 posts
Re: Go: Severe memory problems on 32bit Linux
#52gccgo is better on 32bit systems: https://groups.google.com/d/msg/golang-nuts/qxlxu5RZAl0/NS71... Note that work on the garbage collector is ongoing post-Go1, a faster parallel GC is in process being merged: http://codereview.appspot.com/5279048/ But ultimately 32bit systems don't seem to be a big issue for Google or anyone else using Go in production (and there are quite a few big organizations using it: http://go-l…
yeah, if there wasn't ARM ...
Re: Go: Severe memory problems on 32bit Linux
#53Earlier quoted context omitted.
Yep, that's basically it. It sounds crazy (and it is!) - but it often works reasonably well in practice. SBCL (one of the most performant Common Lisp implementations) has an 'imprecise gc' that works the same way - and I've seen reasonably heavily stressed processes with uptimes in the weeks/months. Remember, even a few years ago (before fastthread, etc) a reasonably loaded Ruby on Rails app couldn't stay up for more…
Would that gc scheme potentially cause the following (pseudo) code to break? x = malloc(1); // allocates block 'a' in memory int i = (int) x; x = 0; i = i - 1; // gc runs here and frees 'a' *( (int*)(i + 1) ) = 123; // failure
In Go, you'd have to be using the unsafe package and some gnarliness to cast between the allocated pointer and int, so you just wouldn't be able to do this in vanilla Go.
Re: Go: Severe memory problems on 32bit Linux
#54Wow. 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 complete…
Keep in mind that the comments on that thread are open to all people and thus that doesn't entail an 'official' response to the problem, though it does unfortunately seem to entail sound (but obviously crazy given the restrictions it puts you under) advice for avoiding the issue.
Re: Go: Severe memory problems on 32bit Linux
#55Earlier quoted context omitted.
Go 1 defines and the backwards-compatibility guarantees one can expect as the language matures. It's more a statement about the language specification than it is about the implementations. I know from experience that the gc 64-bit version is production ready. It's unfortunate that the limitations of the 32-bit version are not called out clearly on the website.
Clearly, there was a need for "Hey, things won't change as much from now on". Now, I'm still afraid little work will appear on the GC, which is IMO Go's biggest weakness to date.
Now, I'm still afraid little work will appear on the GC
No need to guess, look at golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-de...
Re: Go: Severe memory problems on 32bit Linux
#56This 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.
Can anyone knowledgeable about compilers/GCs say why GO went with a conservative garbage collector? From any GO source code its trivial to pick out pointers from values. Is this information hard to preserve at runtime?
Re: Go: Severe memory problems on 32bit Linux
#57Are most Androids 32-bit? Doesn't this issue impact the GO Android SDK adoption?
Re: Go: Severe memory problems on 32bit Linux
#58Earlier quoted context omitted.
Clearly, there was a need for "Hey, things won't change as much from now on". Now, I'm still afraid little work will appear on the GC, which is IMO Go's biggest weakness to date.
Now, I'm still afraid little work will appear on the GC No need to guess, look at golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-de...
Oh yeah thanks. I guess I'm doing it wrong :) Glad to see some work on that front.
Re: Go: Severe memory problems on 32bit Linux
#59Wow. 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 complete…
I am sorry if the post puts Go in a bad light. That wasn't my intention. You shouldn't read the post as "32-bit Go is unusable" - read it as "If you encounter a garbage collection issue in your 32-bit program then you can use the rules mentioned in the post to fix the issue".
Re: Go: Severe memory problems on 32bit Linux
#60Is there a reproducible test case? I can well believe that there might be issues, the post isn't really actionable without some sort of specific code to go along with it :(