invokeDynamic: Evolution of a Language Feature
Dan Heidinga
Presentation had a good technical level and pace.
Showing this applied to static usecases was excellent.
What is it?
invokeDynamic is a relatively new Java 7 feature to support dynamic method calls.
Actually more than a feature, it’s a very rare inclusion of a new bytecode.
I’m a fan of dynamic languages, so i have followed invokeDymanic as an interested observer.
It’s a compiler/tool developer concern, not really used directly by developers, but it’s a very cool VM capability that is worth being familiar with.
Problem: How to efficiently dynamically link?
Old solution is some form of Call-Site-Caching. Â
This is where the implementing dynamic language resolves the method at call-time, then caches the method. Â
The next time around, the context of the call still needs to be examined. Â If the context has not changed, then the cached method is still valid and can be called directly.
This machinery is complex and still slow, and is re-invented by each language implementer.
The VM is unaware of what is being attempted, so can not optimize, and often the generated code is complex enough that the Java optimizer is further disabled.
JSR292 - InvokeDynamic
JSR292 was created to solve the problem of dynamic linkage and typing.
Cases where non-Java language semantics are not consistent with Java.
non-Object based.
use of metaclasses.
use of multiple dispatch.
What the invokeDynamic bycode does
Bootstrap is called with the full context of the first call of a method (includes caller, method name, descriptor, other data).
You can implement Bootstrap to interpret this context however you like. Â You must finally return a CallSite object.
The CallSite object holds on to the target method.
The invokeDynamic instruction is bound to the resulting CallSite instance forever.
CallSite includes hints of the stability of the target method (”constant” will never change, “volatile” can change ever call,...)
These characteristics make dynamic calls very flexible and allow the VM to apply very good optimization.
In the case of “constant” CallSites, the performance will match static method calls (after warmup).
Switchpoint is the ability to externally invalidate callsites.
invokeDynamic can be use to implement sematics beyond just simple method calls.
lazy constants.
new semantics.
new bytecode prototyping.
The question was asked (which is a good one)...
What is a dynamic language anyway?
The speakers made the point it is not black/white, that there really is a spectrum, and there are many dimensions.
compile time vs. runtime.
typing, dispatch (static in Java)
binding, loading (dynamic in Java)
Most interesting was the point that Lamdas have been implemented within Java (a supposedly static language) using InvokeDynamic.
Couple of big benefits.
This allow runtime-based optimizations to be applied.
** It allows a new language feature not to require VM internal implementation. Â This is normal Java lib code. Â So it keeps the core VM smaller and more simple.
Another example that may be coming in Java9 is a String concat optimization.
eg.
String concat = a + "|" + b + "|";
This form of code is very inefficient, but used a lot.
The compiler can use invokeDynamic to generate a callSite that is passed the entire list of concatenations, which can then be optimized (at runtime).
The prototype of Java10 parameterized types over Value Types is also using InvokeDynamic. Â
This allows the VM implementation to be much more simple since we do not have to modify the JVM, and nice separation concerns.
