Ruby 1.9.3 Preview 1 is out and brings along additions to the API, as well as an update to the GC, the lazy sweep GC.
InfoQ caught up with Narihiro Nakamura, who contributed the lazy sweep GC changes to Ruby 1.9.3.
InfoQ: How is the lazy sweep GC different to the previous GC?
Simple (non-lazy) Mark Sweep GC executes mark and sweep atomically. Also, it sweeps the whole heap and links all live objects to the freelist.
In Lazy sweeping, each invocation of the object allocation sweeps the heap until it finds an appropriate free object.
InfoQ: So is the main advantage of the lazy sweep GC shorter pause times? Ie. the pause time is limited to the time it takes to find enough free space to continue?
Right. Lazy sweeping improves the response time of GC, ie. worst case time decreases. However, It decreases overall throughput of GC.
I have compared the Simple M&S GC and the Lazy sweep GC in MRI using a benchmark program (http://redmine.ruby-lang.org/attachments/959/bm_gc_fragmentation.rb).
Max GC time：48.00ms => 28.00ms (58%)
All GC time：0.83ms => 0.92ms (110%)
InfoQ: Do you know of any types of program behavior where the lazy sweep GC is not better?
If the program creates many long-lived objects, lazy sweep may not be able to find a free object. In that case, lazy sweep spends a long time on a single object allocation. I think that in most cases, the performance of this should still be better than M&S GC.
InfoQ: Do you have any plans for future GC work or improvements for MRI 1.9.x?
Yeah, I'm creating a parallel marking GC for MRI.
Currently, generating the RDoc documentation (using 'make rdoc') takes about 80 seconds on my machine. 30% of that time is spent on GC. I managed to improve this GC time by roughly 40% on 2 core CPU machine.
I plan to talk about this on RubyConf 2011.
The implementation of lazy sweep GC is in Ruby's gc.c, in particular the the lazy_sweep and the the gc_lazy_sweep functions.
The changes to the Ruby standard library can be seen in the Ruby 1.9.3 Preview 1 Release Notes. Another change concerns the license, according to the Release Notes: "Ruby's License is changed from a dual license with GPLv2 to a dual license with 2-clause BSDL.".
With Ruby 1.9.3 on the horizon it's time again to look at the state of Ruby 1.8.x vs Ruby 1.9.2. Ruby hosters have been moving in the direction of 1.9.x for while now. Heroku introduced the Cedar stack, which powers their PaaS; Cedar offers Ruby 1.9.2, no 1.8.x. Engine Yard's AppCloud now defaults to Ruby 1.9.2.
Previously scheduled as another intermediate release to help developers migrate to 1.9.x, Ruby 1.8.8 has been cancelled. Ruby 1.8.6 is pretty much on it's way out too, particularly with libraries such as RDoc 3 dropping support for it in favor of 1.8.7.
The status of Gems supporting 1.9.x can be seen on isitruby19.com.
What's keeping you on 1.8.x?