CrossTwine aims to improve the performance of existing Ruby and Python runtimes. A high level explanation of CrossTwine Linker:
In a nutshell, it observes the run-time behavior of your objects and functions, and optimizes the common case by removing dynamism where it is not needed‚ While still providing complete safety. We go over quite a bit of the nitty-gritty in the Technical White Paper.
Ruby 1.8 and Ruby 1.9.1 versions with the CrossTwine patches are available as binaries for Linux.
Looking for source for the CrossTwine technology and the integration into the VMs won't yield any results; the technology is closed source. The company instead wants to focus on providing services, helping to improve Ruby or Python applications with the CrossTwine technology:
As a services business, the CrossTwine Linker kernel allows us to quickly develop language-, domain-, and even problem-specific interpreters tuned for specific needs: in effect, we can choose (and expand) the level of partial specialization if we know about the target problem. We 'cheat' safely, however: a problem-specific customization remains 100% compatible with the language, but can be much faster on some kinds of workloads.
Despite that, some simple benchmarks show the available binaries run code faster than the plain runtimes. However, one of the developers of CrossTwine mentions that the current first alpha version only optimizes certain code:
Speeding up real-world applications can actually range from being very easy to incredibly difficult, depending on the facilities they rely on. And we are far from finished: while number-crunching applications can see substantial speed-ups, Rails is currently not accelerated by our modified interpreters.
Some more technical information is provided in a Whitepaper (PDF). One optimization improves inline caching and message sends.
Another optimization tackles the lookup of instance variables, by improving the repeated lookup of a variables. Other lookup optimizations, similar to Google Chrome's V8 for Javascript objects, are planned but not active at the moment.
The company has a Twitter presence at http://twitter.com/crosstwine.
CrossTwine comes shortly after the announcement of the Unladen Swallow project in the Python space. The team behind Unladen Swallow, which, according to the website, consists of a few Google employees, forked the current VM and plans to add performance improvements - in the hope that their changes might get merged into the official branch. One of the planned optimizations is to improve the efficiency eval loop of the bytecode interpreter by replacing slow bytecode dispatch with faster methods (direct threading or others). Another planned item is to get rid of the GIL (Global Interpreter Lock), which also exists in Ruby 1.9.x, and only allows one thread to execute Python code at a time. Further plans include a generational GC and finally a JIT, possibly implemented using LLVM. Unlike CrossTwine, Unladen Swallow is open source.
Finally, when it comes to improving the efficiency of an old VM, the Cog VM is a project to watch. It's a significantly overhauled version of the Squeak VM by Eliott Miranda.