Rubinius would benefit from being the go-to solution for high-performance Ruby on ARM devices.
I discussed this matter with @brixen and @YorickPeterse on IRC. They mentioned that the main blocker is the JIT (and possibly memory management), which would require some nontrivial changes.
According to @brixen, the first step here is to create a viable workflow for testing the builds on an ARM VM.
Here are some notes on emulating debian arm with qemu static on a debian host (which could itself be a debian x86 VM):
Here is an article based on the above technique that gives a script for testing ARM on Travis CI, but it looks like doing so for rubinius would likely overrun the time limit (50 minutes), but this is not something I am sure of.
Here is a tutorial from the LLVM team for migrating one of their example interpreters from the old JIT to MCJIT, which should provide some illumination into what would be required to migrate Rubinius:
Particularly, it looks like the most nontrivial part of the migration (if I understood the post correctly) is that compiled modules are truly finalized, and the strategy of simply adding new functions to compile to the existing monolithic module no longer works. Instead, you have to create new modules and 'link' them together.
@jemc So the most complicated part is actually the memory management. We use our own custom memory manager for jit'ed code so we don't suffer from memory leaks in LLVM. They aren't so much memory leaks, but if you keep reusing the same LLVM context over and over again it will keep growing in memory use. It will only free the memory once the context is deallocated, not after each jit request we handle.
Being able to free memory after each jit request is why we had to implement our own memory management parts, so we have to completely reevaluate those parts when looking at using MCJIT.
I have a working virtualbox VM for doing ARM builds, in the style discussed above.
How do you want me to share this? Just the scripts I used, or should I also post the VM files on a file host somewhere?
As a note for the future: I came upon this post which states that optimization level -o1 should be used when compiling LLVM on ARM. So, we should keep that in mind.