mstoodle
Depending on how smoothly your experimentation went, you may also have to destroy a pre-existing cache before you really measure it (java -Xshareclasses:destroy) as it could have stale classes in it from an earlier run.
Would you be willing to open an issue with more details at http://github.com/eclipse/openj9/issues so we can look into it?
Disclaimer: I am a project lead for both Eclipse OpenJ9 and Eclipse OMR.
OS X has been talked about, but we have a lot of plumbing to connect up at the project right now and that has high priority for us. If someone wants to kick that work off, I would happily encourage it :) .
I strongly disagree (and always have) with your statement that repurposing a statically typed JIT is limiting. The JIT projects you mention get lots of their performance from profile data which essentially presents type guesses so the compiler can speculatively optimize and recover when that info is wrong. Guess what? That's what statically typed Java JIT compilers do too, and the OMR compiler is no different, though we haven't sunk all that capability to OMR from Testarossa just yet (it's coming!).
I would be a lot happier with you repeating, or at least not propagating specifically the opposite conclusion, this line from your own paper:
On page 16, under Conclusion: "Our point, however, is not to argue against the repurposing of JIT compilers, but to define guiding principles and to promote techniques to construct an effective RJIT compiler."
Since this article was written, the entire Testarossa code base has been substantially refactored and parts of it rewritten (by the production Testarossa team) and streamlined to make it more amenable to dynamic optimization of other languages. We haven't finished that process (there's still more stuff we need to pull into the OMR compiler technology), but I really think your provocative statement above promotes a very broad conclusion from a research project that unfairly tries to close the door on what I still believe is a very reasonable technology evolution path. Especially since the article's conclusion is based on one research project for one language and one runtime where IMO the most reasonable conclusion is that just adding a JIT to an existing runtime is not enough to compete with a project that rewrote the entire runtime. That doesn't mean existing runtimes have nothing but bespoke paths forward or that reusable JIT technology cannot play a substantial part in that runtime's future evolution.
Finally, note that the OMR technology is being used (commits pulled in on an hourly basis) to build the production J9 JVM, which is also slated to be open sourced this year. There are also projects to use OMR for Ruby (see original post :) ), Lua, Rosie, Smalltalk (SOM++), Javascript, Python (currently inactive), and a runtime for workshops called Base9. I can provide links for the ones that have been open sourced already if people can't find them on github.
For those kind enough to have read to the end of this response (thank you!), please know that we have proposed several GSoC projects [1] to port to other languages and we're pretty open minded and positive about the potential and possibilities of reusing the Eclipse OMR compiler and other runtime components. Feel free to suggest alternative projects if you have a particular area of interest since we have lots of interested mentors available!
[1] https://wiki.eclipse.org/Google_Summer_of_Code_2017_Ideas#Ec...