While the 'Pitfalls' paper was implemented on top of the Testarossa compiler technology (that underlies the OMR compiler technology), the OMR project has spent a lot of engineering effort to make the technology more modular and easier to interact with.
While it doesn't invalidate the reasoning behind the 'Pitfalls' paper, we think that we're addressing the problem in a fairly different manner: Instead of providing a fully featured JIT compiler that you need to wedge the language into, we've instead chosen to create a more modular system that lets the JIT compiler be more customized to the target language and VM.
Alas, our connection Eclipse is only a legal one. We are an Eclipse Foundation project, but not directly related to the IDE. So won't have any impact on eclim. Sorry!
When you say "native languages" you mean a statically compiled language?
It's been done before with the technology underlying the OMR compiler component, however there is some work that would need to be done to support this.
In principle though, there's no reason it couldn't be done.
I really enjoy meeting up with the JRuby+Truffle people whenever I can at conferences. Though our approaches are really different, there's definitely a cross-pollination of ideas: I've taken huge amounts of inspiration about what could be possible from Chris Seaton's PhD work which was on JRuby+Truffle.
Once that's stable, then I'd like to focus on trying to some of this code integrated into MRI upstream, perhaps as an experimental branch for the 2.5 development cycle, or as something that can be compiled in optionally.
In parallel, I'd like to work on improving performance . We've not put a lot of effort into performance, and have instead focused on compatibility and currency, so that we have a good base from which to grow performance on top of.
Thanks! That's definitely the exact hope we have for OMR as well.
Similarly, improvements in OMR can be shared among all languages using it; ie, because we build both IBM's Java JDK and Ruby on top of OMR, Ruby can benefit from investment in Java, and Java can benefit from improvements in the Ruby community.
Officially, OMR is a meaningless title, like LLVM. Similar to LLVM, it once stood for something, but then we realized that it didn't actually match the project's 'charter' quite as well as we had hoped... but had grown fond of the name (also... finding new names is super hard).
Original definition was 'Open Managed Runtimes', but we can do more than just managed runtimes with OMR technology, and so that seemed to sell it short.
Ruby+OMR is developed in three pieces: 1) the language independent core, then 2) The language dependent portions (i.e., the VM, and what we call the 'glue')
OMR Team member here: Glad to hear you had a good experience with our tech preview! We really appreciated the feedback you provided, and would definitely be willing to take more.
As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.