I have to say that I'm not too thrilled by this move to VMs by everyone in the Ruby world. One of the things that I absolutely love about Ruby 1.8 is that when performance is a dog I can just replace the slow Ruby code with fast C code. Writing extensions is dead easy. With a VM this can ony be a much more convoluted process.
An example (which is a bit Russian Dolls nested in nature) - I recently wrote a tool that takes various modules from a C project with an embedded target, and places them inside a VM to obfuscate the code. Because it's embedded code, we needed to be able to only place selected modules in the VM, for performance reasons, but we needed the transition between VM and native C code to be transparent (Basically, everything is coded in C, but we compile some modules for the VM, not the target).
To make this work, I wrote a tool that generates glue code to cross the interface. Code is generated automatically for both sides of the interface. This requires the use of a C parser, which for performance reasons is mostly written in C. But the high level analysis is done in Ruby, as is code generation, various sandbox management tasks and other peripheral tasks. If I couldn't have written the front end of the parser in C using yacc, the performance would be horrible. As the sandbox is quite large (300 000 lines of code), performance of the parser is a major issue. I don't know how easy it is going to be to port this stuff to the new impls....
An example (which is a bit Russian Dolls nested in nature) - I recently wrote a tool that takes various modules from a C project with an embedded target, and places them inside a VM to obfuscate the code. Because it's embedded code, we needed to be able to only place selected modules in the VM, for performance reasons, but we needed the transition between VM and native C code to be transparent (Basically, everything is coded in C, but we compile some modules for the VM, not the target).
To make this work, I wrote a tool that generates glue code to cross the interface. Code is generated automatically for both sides of the interface. This requires the use of a C parser, which for performance reasons is mostly written in C. But the high level analysis is done in Ruby, as is code generation, various sandbox management tasks and other peripheral tasks. If I couldn't have written the front end of the parser in C using yacc, the performance would be horrible. As the sandbox is quite large (300 000 lines of code), performance of the parser is a major issue. I don't know how easy it is going to be to port this stuff to the new impls....