It began during RailsConf.
My fingers were itching to code, so between sessions I started tinkering with some of the more fanciful enhancements to The Ruby Racer I'd been contemplating as well as wrestling with a number of long-standing bugs. But what started out as a small refactoring slowly but relentlessly gained momentum until things were completely out of control.
By all accounts my hands were steady and the work proceeded in an orderly fashion. Instead, it was I who was out of control. Personally and psychologically I was helpless to stop myself as line after line, class after class unravelled before me --each one more rapidly than before. Soon a critical mass was achieved and boom! Nuclear. A from-scratch rewrite was underway.
Yes it was a rewrite, but by the time I was aware of it, I was too deeply invested to turn back.
It's a tichy thing, is a rewrite. Instead of the careful, iterative approach that serves as law in our profession, you drop everything and sprint towards the cliff in the hope that you can lunge across the chasm in in one leap. Once you're in the air there's no going back, and the possibility is as thrilling as it is real that, like Icarus, you'll hurtle into the abyss... another unsung casualty of hubris.
The prize of course is a better library that is more stable, has more features and is easier to build and install, so if a rewrite it had to be, I did the only thing I could do yield myself to it utterly.
I'm happy to say that it's mostly there there and that, despite some outstanding flaws, I'll be releasing the next version shortly. But more on that later. First, what's new?
Stability
For certain applications therubyracer has been plagued by crashes and memory leaks that have limited its usefulness to a much smaller domain than necessary: specifically, low-traffic applications that only instantiate a single JavaScript context. These problems stemmed from within the library but also from within Ruby itself.
The Ruby Racer relies heavily on weak references in order to maintain referential integrity between Ruby object and the JavaScript objects they represent (and vice-versa). Sadly, the WeakRef implementation on 1.9 is completely broken. This is unfortunate because functioning weak references are sometimes a necessary component for building correct programs on platforms with garbage collection. Luckily there are workarounds which have been deployed while we wait for 2.0.
But that's not the whole story. It would be a shameful misrepresentatio to lay the bulk of the blame on Ruby's door. Distributed garbage collection is hard, and The Ruby Racer engaged in all manners of evil hackery and dark GC foo in order to prevent cycles of garbage from spanning the Ruby and JavaScript VMs. Sadly, this did not work in the general case, and furthermore, was not portable to other Ruby implementations (or even Ruby versions).
I've come to realize that to solve these memory problems in the general case would require each host Ruby platform, as well as V8, to expose a uniform interface to its garbage collector so that The Ruby Racer can traverse its object graph in order to detect cycles of garbage. In other words "not bloody likely."
As a fallback, I've decided to throw up my hands and eschew GC histrionics in favor of more sane memory management in the C extension combined with an explicit teardown mechanism for cases where cycles of garbage do occur. e.g.
context = V8::Context.new
context['cycle'] = context #oh no, a vicious cycle!
context.dispose() # Gordion knot is cleaved, sir!In exchange, we get a kinder, gentler racer that works on MRI as well as Rubinius, and which you'll be able to rely on in your production processes.
Resource Constraints
Speaking of production, the upcoming release contains a much more comprehensive coverage of underlying V8 functionality than every before.
Among other things, you can query the V8 vm for heap usage by young generation, old generation as well as absolute heap size including executable memory. Not only that, but you can also place hard caps on each of these numbers. That way you can contain memory usage and keep your processes under control; even in a resource constrained environment like Heroku.
A (hopefully) kinder build
One of the sorest pain-points with The Ruby Racer was the way it built. Prior to 0.11, it had a hard dependency on the libv8 rubygem in order to provide the actual V8 library. In retrospect, this was a bad idea.
If you were unable to build the v8 contained in the libv8 gem, then you were completely hosed. You could not use therubyracer at all. Or, if you wanted to use a custom v8 patched for security or with tweaked startup data, then you were out of luck. Finally, it raised an unnecessary barrier to distributing therubyracer as a binary gem (which I would like to do more of). If you have a binary version, then why do you need to have libv8 at all?
For these reasons, the dependency on libv8 has been converted to a soft one. If a compatible version is detected in your rubygems, then it will compile and link against it. However, if for whatever reason, you do not want to use the libv8 gem to build, then that is now your prerogative. The Ruby Racer will search your system for v8 just like any other library.
The only difference is that if you want to use the libv8 gem, then you will have to explicitly require a compatible version in your Gemfile.
More bugs, but not on Rubinius
There are still some outstanding issues on MRI that emerge under a heavy stress of rapid object allocation and deallocation. As far as I can tell they are related to to the weakref implementation, wherein MRI gets confused and starts handing back references to completely unrelated objects. I say "as far as I can tell" because the subtleties involved lie beyond the frontier of my understanding of MRI internals. Given my current workload, it is unlikely I will have time to make the necessary investment in understanding required to completely quash these problems.
Despite this, I'm releasing the new version anyhow in order to support Rubinius more fully and because I think that even on MRI it will solve more problems than it introduces.
For starters, 0.11 is very stable on Rubinius and that platform is long overdue for a version of therubyracer that doesn't suck. The Rubinius core team, and @dbussink in particular, have been very patient and helpful in helping me resolve all the lingering crashes both big and small... even going to the trouble of adding checks and diagnostics to the garbage collector just for my sake. They were even willing and often able to diagnose problems I was having on MRI in order to make the library for everybody. If anything, I feel that they deserve a functioning JavaScript environment and it wouldn't be fair for me to withhold it from them.
On the MRI front, I still think that closing some of the loopholes in the memory management, the enhanced extensibility, and better build make it worth releasing anyway. I've been recommending people to upgrade to the beta for almost 3 months and it is almost always the right decision. Given that I have neither the time nor the inclination to support what I now consider to be the legacy release, I think it's high time to either shit or get off the proverbial pot.
If you, or anybody you know has a deep knowledge of MRI internals and would be willing to help me address these issues as well as others that may arise, I would love to work with you to knock 'em down.
So this is why I'm releasing version 0.11.0 of The Ruby Racer today. Of course, I may
come to quickly regret it, but that's what gem yank is for right?