Invokedynamic in JRuby: Constant Lookup

In your example, we would never enter the optimized code path without knowing that the constant's still the same as last time. Since no loop is emitted, there's no deoptimization mid-loop required. So we either run the optimized code, or we never get to the optimized code.

If a deopt is required mid-loop, Hotspot inserts a "trap" that would see the deopt command and immediately branch to the interpreter with the current state.

Of course there's limits to how far optimization can go, but having a way to tell Hotspot that there's a known-immutable constant object reference at this point in the code opens up a lot of opportunities.

The best you can do with DLR is regenerate little dispatch stubs at each dynamic call site, to at least avoid the overhead of re-searching the class hierarchy. These stubs are then reinserted at the dispatch point and used to make the call.

Unfortunately, since all current CLR implementations do not optimize code at runtime, these newly-created stubs can't be optimized with the rest of the code. So you get a call from the code to the stub, a few guards, and another dispatch from the stub to the target. Those three pieces never optimize together.

invokedynamic is also very useful for optimizing things other than method dispatch. In JRuby master, we're using invokedynamic for constant lookup (as illustrated in this post) and for lazily creating literal values. In both cases, it reduces the access to a single memory hit, much faster than what JRuby 1.6 or any DLR languages can do.

tl;dr: DLR is the best you can do for dynamic dispatch optimization at an API level atop current CLR impls and subject to limitations therein. invokedynamic brings true end-to-end dynamic dispatch support to the JVM.

I will probably do future posts with less synthetic benchmarks, but it's ultimately just hard to benchmark a specific language feature in the presence of optimizations like the JVM performs.