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.