A History of the Rubinius Ruby JIT(ruby-compilers.com)
ruby-compilers.com
A History of the Rubinius Ruby JIT
https://ruby-compilers.com/rubinius/
9 comments
Oh wow I didn't know the JIT had been removed from rubinius.
I was a (pretty minor) contributor to rubinius back in its llvm heyday and it was a pretty transformative project for me, in terms of enabling my understanding of VMs, garbage collection, and language architecture. Even then llvm felt like a pretty heavy weight for JIT uses, but there really wasn't anything else out there then that could perform at its level. I think nowadays there'd probably be some better choices out there. Maybe cranelift.
I wound up spinning a lot of that off into my own attempt at a "VM built in itself" project that never got to the point of JITing code it did run its own "glue language" (compiled by ruby code into vm bytecode) that was used to build somewhat functioning ruby (passed like 70% of then-current rusbyspec I think?) and python support without the VM itself being aware of the language semantics. It was a really fun time in my career.
Later I used the basic understanding of LLVM it gave me to take part in the effort to port Swift to linux even, which was also a really good time for me.
I was a (pretty minor) contributor to rubinius back in its llvm heyday and it was a pretty transformative project for me, in terms of enabling my understanding of VMs, garbage collection, and language architecture. Even then llvm felt like a pretty heavy weight for JIT uses, but there really wasn't anything else out there then that could perform at its level. I think nowadays there'd probably be some better choices out there. Maybe cranelift.
I wound up spinning a lot of that off into my own attempt at a "VM built in itself" project that never got to the point of JITing code it did run its own "glue language" (compiled by ruby code into vm bytecode) that was used to build somewhat functioning ruby (passed like 70% of then-current rusbyspec I think?) and python support without the VM itself being aware of the language semantics. It was a really fun time in my career.
Later I used the basic understanding of LLVM it gave me to take part in the effort to port Swift to linux even, which was also a really good time for me.
I've never used Rubinius in production but over 10 years ago, when I was still relatively new to Ruby, I used to read Rubinius source code to understand how some Ruby methods worked under the hood.
Even though Rubinius has never reached the popularity it aimed for, I'm forever grateful for the effort that's been put into creating it.
Even though Rubinius has never reached the popularity it aimed for, I'm forever grateful for the effort that's been put into creating it.
Hi, Evan Phoenix, Rubinius creator here. I just wanted to stop in and say thank you for this comment. It means a lot to me, even after all these years that Rubinius helped you out.
I mentioned this on twitter as well (https://twitter.com/evanphx/status/1458912013011152898?s=21) but wanted to reach out here and let you know personally too.
Thank you.
I mentioned this on twitter as well (https://twitter.com/evanphx/status/1458912013011152898?s=21) but wanted to reach out here and let you know personally too.
Thank you.
Hi Evan, I'm happy you found this comment heartwarming. Your work on Rubinius (and even more - Puma!) was really amazing, it had a big influence on my career
It was incredibly useful for that, except for the occasions where Rubinius got things wrong. :-)
It was also fascinating seeing how the abilities of their VM fed into the design of the core library. I remember soon after starting work on TruffleRuby starting to look into the performance of some string methods and doing extensive refactoring because the type of code that performed best for us was very different.
It was also fascinating seeing how the abilities of their VM fed into the design of the core library. I remember soon after starting work on TruffleRuby starting to look into the performance of some string methods and doing extensive refactoring because the type of code that performed best for us was very different.
I didn't even know Rubinius was still around.
Last I knew, they worked hard to develop a standard and test suite for 1.9.x which the Ruby team used for one release before promptly breaking everything.
It's yet another example of why programming language standards are important.
Last I knew, they worked hard to develop a standard and test suite for 1.9.x which the Ruby team used for one release before promptly breaking everything.
It's yet another example of why programming language standards are important.
Yes that's https://github.com/ruby/spec - now primarily maintained by TruffleRuby people.
The new RubySpec is an independent resurrection years after the original project was abandoned, I think.
I haven't touched my compiler much for most of last year and this year, but I have a half-finished GC sitting my local tree that I really should wrap up. At the moment what's stopping it from compiling itself correctly is a couple of small bug fixes plus some GC and overall allocation improvements (it's creating way too much garbage to start with, which I'm sure you noticed).