InvokeDynamic
From APIDesign
(→Drawbacks) |
|||
| Line 12: | Line 12: | ||
=== Drawbacks === | === Drawbacks === | ||
| - | [[ | + | The major problem with [[invokeDynamic]] is, well, that it is dynamic! [[Java]] is statically typed language and all field, method types and parameter types are known to [[JavaC]] before its emits the bytecode. |
| + | |||
| + | Yet, as [[JavaC]] from [[JDK]]8 is emulating [[Closures|lambdas]] with [[invokeDynamic]] it forgets all the type information and generates [[invokeDynamic]] which is supposed to do late binding - e.g. find out the right types at the invocation time. | ||
Revision as of 09:28, 17 August 2014
When I was younger I believed that having invokeDynamic instruction in HotSpot VM can be beneficial. I even argued that the instruction should not be used just for languages like Ruby but rather by the core Java to implement lambdas. Now, after spending time to implement lambdas in my Bck2Brwsr VM and seeing things from the other side I have to admit I was wrong. invokeDynamic is wrong idea (especially for implementation of lambdas).
Benefits
Implementing different languages on top of HotSpot virtual machine is of different complexity. The most problematic thing is to properly and effectively dispatch methods calls. Not every language uses the Java rules. Some support type conversions, implicit arguments. Some can dynamically alter the existing dispatch target or strategies. More about that in an excellent summary Bytecodes meet Combinators.
To address all these different needs the new invokeDynamic bytecode operand does not hardcode the actual invocation, but delegates it to software controllable MethodHandles. What is a method handle? A pointer to method of some signature (for example plus would take two ints and return their sum as an int) and an object - a receiver to call the method on. However this is nothing else than a closure.
The proposed improvements to the HotSpot virtual machine may help the JDK to support different languages, but first and foremost they open the door to effective implementation of Closures.
Drawbacks
The major problem with invokeDynamic is, well, that it is dynamic! Java is statically typed language and all field, method types and parameter types are known to JavaC before its emits the bytecode.
Yet, as JavaC from JDK8 is emulating lambdas with invokeDynamic it forgets all the type information and generates invokeDynamic which is supposed to do late binding - e.g. find out the right types at the invocation time.
Follow
