Unlocking Ractors: Object_id

Summary

In a previous post about ractors, I explained why I think it’s really unlikely you’d ever be able to run an entire application inside a ractor, but that they could still be situationally very useful to move CPU-bound work out of the main thread, and to unlock some parallel algorithm. But as I mentioned, this is unfortunately not yet viable because there are many known implementation bugs that can lead to interpreter crashes, and that while they are supposed to execute in parallel, the Ruby VM still has one true global lock that Ractors need to acquire to perform certain operations, making them often perform worse than the equivalent single-threaded code. But things are evolving rapidly. Since then, there is now a team of people working on fixing exactly that: tackling known bugs and eliminating or reducing the remaining contention points. The one example I gave to illustrate this remaining contention, was the fstring_table, which in short is a big internal hash table used to deduplicate strings, which Ruby does whenever you use a String as a key in a Hash. Because looking into that table while another Ractor is inserting a new entry would result in a crash (or worse), until last week Ruby had to acquire the remaining VM lock whenever it touched that table. But John Hawthorn recently replaced it with a lock-free Hash-Set, and now this contention point is gone. If you re-run the JSON benchmarks from the previous post using the latest Ruby master, the Ractor version is now twice as fast as the single-threaded version, instead of being 3 times slower. This still isn’t perfect though, as the benchmark uses 5 ractors, hence in an ideal world should be almost 5 times faster then the single-threaded example, so we still have a lot of work to do to eliminate or reduce the remaining contention points. One of such remaining contention points, that you likely didn’t suspect would be one, is the #object_id method. And on my way back from RubyKaigi, I started working on tackling ...