Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Support the ARM architecture #2867

Open
jemc opened this Issue · 4 comments

3 participants

@jemc
Collaborator

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.

@jemc
Collaborator

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):
http://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/

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.
http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html

@jemc
Collaborator

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:
http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html

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.

@dbussink
Owner

@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.

@jemc
Collaborator

I have a working virtualbox VM for doing ARM builds, in the style discussed above.

@brixen, @dbussink:
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.

https://ghc.haskell.org/trac/ghc/wiki/Building/ARMLinuxGnuEABI

@YorickPeterse YorickPeterse added the ARM label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.