3 ms·

I'm just starting to get into Ruby but I'm pretty confused about this project. It sounds really cool, but doesn't Ruby 1.9 already have a GC and compiles into

• Freaky 16y ago
  Ruby has had a GC since the start; it's a conservative stop-the-world all-or-nothing non-compacting mark-and-sweep garbage collector. Meaning: 1. It can't tell the difference between a number on the heap that happens to look like a reference to some active data, and an actual reference to some active data. Hence it has to be conservative, and assume anything that looks like a reference, is one. Rubinius has a precise GC, and so doesn't suffer from this problem, which can lead to dead objects never being collected. 2. The GC has to stop the VM while it's running. This is probably also the case with Rubinius, however: 3. It has to walk over every object in the VM in one go, so it gets progressively slower the more objects you have. Rubinius has a generational GC, where objects are split into pools based on how long they've been alive for, and these can be scanned individually and at different rates appropriate to their age (i.e. long-lived objects probably aren't worth checking very often). 4. It can't move objects around; when it frees something, it leaves a gap where the object used to be. If a new object doesn't fit there, it has to go somewhere else, wasting that space. In the long run this can lead to memory fragmentation. Rubinius has a compacting GC, allowing it to fill in these holes and make better use of memory, and also better use of CPU caches. Yes, 1.9 compiles to bytecode, and yes in theory a JIT could be added to it, but that's a pretty big project.