It's unclear how much benefit invokedynamic actually provides at present, I recall seeing benchmarks not showing much.
I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4.2 have occasionally run into relatively minor worked-around-able issues.
My impression is that code written for standard Python tends to have a lot more trouble running on Jython -- not from any fault of Jython, but because 'standard' Python code tends to be more likely to use native C than typical ruby.
Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are cases where simply inlining the code together doesn't lead to a measurable increase.
Given that both you and Chris are posting to this thread, I was kind of surprised to learn that you're planning to focus on a non-Truffle compiler/optimisation engine in future. Isn't Truffle meant to give huge speedups? It sounds like you might eventually get JRuby 9000 to be faster than MRI but that a rewrite of the current code didn't do it yet.
Is there some kind of vision or plan for how Graal/Truffle fits into the JRuby roadmap?
Truffle is a research project. It is not a short-term goal to replace the current IR-based runtime in JRuby, and Truffle isn't really part of the 9k release (it's there but I wouldn't recommend trying to use it).
We are working towards being fully compliant and we're getting there fast - I think with four full-time people and more in support we are now the largest employer of Ruby implementors anywhere. But since we aren't ready yet, stopping work on IR isn't an option even if we wanted to do so and we all need Charlie and Tom to continue their excellent work on the IR.
In my personal view, Truffle will be good enough to replace JRuby runtime at some point in the next couple of years, but we aren't advocating for this now and if it did happen it would be because the JRuby community and leadership make that decision for themselves.
I think we might come up with some kind of roadmap, or at least stated plan, at JRubyConf next week.
I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4.2 have occasionally run into relatively minor worked-around-able issues.
My impression is that code written for standard Python tends to have a lot more trouble running on Jython -- not from any fault of Jython, but because 'standard' Python code tends to be more likely to use native C than typical ruby.