Hacker News Reader

Comment by xal | Hacker News Reader

Just compile with the gcc go compiler and you are set. Running 32 bit on servers is just like running IE6 on desktops. It's time to upgrade. Also every language that uses a conservative GC behaves this way, it's not just a GO issue.

View on HN

No, gccgo doesn't resolve anything. No, this is not intended to be server code. No, its not time to upgrade. No, the dominant GC languages (java, c#, python, ruby, and on and on) do not suffer from this problem (at least, not to the same extent).

No, gccgo doesn't resolve anything.

Care to explain? I was under the impression that the recent 32-bit memory usage issues are specific to the 8g implementation only.

The memory issue at hand isn't the same as the one that plagues the conservative GC. This is a Windows-specific problem around the reservation of contiguous address space, not a failure of the GC to collect memory that isn't in use.

What other popular languages use a conservative GC, though?

I believe Mono uses Boehm GC, which is conservative:

http://www.mono-project.com/Mono:Runtime#Mono.27s_use_of_Boe...

They've introduced S-Gen which is a good, precise, generational collector. I don't know if it's the default, but it is considered production ready IIRC.

It'll be the default in Mono 3.0 (or 2.12, whatever we decide to call it). Currently, in Mono 2.10, Boehm GC is the default, although we've been using SGen for our commercial products (which is why we feel that SGen is now ready to be the default).

And yet Mono works fine in environments with < 512MB of RAM, even when using Boehm GC :-)

That's because the conservative GC issue is separate from the low-RAM issue.

Last I checked, Ruby uses a conservative GC. It uses one bit of every variable as a flag to unambiguously identify pointers, so that's a free pass on the integer-aliasing problem Go experiences. (Of course, the problem described in the OP is different and has to do with how Go allocates memory.)

Maybe I'm confused about what's going on, but if Ruby unambiguously identifies pointers at runtime, and the GC takes advantage of that, wouldn't that not be a conservative GC?

The point is that there isn't any integer that looks like a pointer — odd numbers are immediate, even are addresses — so Ruby's GC is spared from having to figure it out. It avoids the problem as a side effect of a performance optimization in the language implementation, so the GC doesn't have to be smarter. The compromise is in losing a bit of integer precision. But now that I think twice about it, I suppose I might kind of be splitting hairs.

Well, I'm not sure what you call it, but if you can't even have an integer that looks like a pointer, then you effectively don't have a conservative collector. The important distinction is whether an object can be kept alive through a false reference, and it sounds like it definitively can't in this case.

Reply on news.ycombinator.com