This post originated from an RSS feed registered with Ruby Buzz by Laurent Sansonetti. Original Post: ruby+objc, Part 2 Feed Title: lrz's diary Feed URL: http://www.chopine.be/lrz/diary/xml/rss/feed.xml Feed Description: lrz's diary Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Laurent Sansonetti Latest Posts From lrz's diary

ruby+objc (briefly introduced here, and yes I still need a better name) uses a new garbage collector, the same that has just been introduced with the new version of the Objective-C runtime in Leopard.

The collector is generational, and uses write barriers to filter modifications inside the object store and therefore quickly collect generations of young objects. The Ruby runtime was deeply modified to explicitly set the write barriers.

Collections can happen in a separate thread, which doesn't stop the execution of the main one. Due to the current nature of Ruby 1.9, on which ruby+objc is based upon, finalizers must acquire the giant lock though. Fortunately, only a couple of classes seem to require a finalizer (IO and some T_DATA classes).

Despite having a more reliable collector, this change is also very interesting because it means that both Ruby and Objective-C objects are now issued from the same memory pool, and managed by the same garbage collector.

(gdb) p (void *) [[NSObject new] zone]
$1 = (void *) 0x14ab000
(gdb) p (void *) [[RBRegexp new] zone]
$2 = (void *) 0x14ab000
(gdb) po NSZoneName(0x14ab000) 
auto_zone

More to come: some interesting benchmarks.