As announced by John Rose, The early draft review for JSR-292 has been released on the heels of JavaOne. JSR-292 is an effort to define the specification of the invokedynamic instruction for the Java Virtual Machine.
InfoQ previously covered JSR-292 in October as part of the initial announcement for the Da Vinci Virtual Machine Project (MLVM), a test bed for technologies like invokedynamic.
John Rose, who is the specification lead for JSR-292 and primary individual behind the MLVM, has provided regular discussions on his blog with respect to making the JVM more accessible to dynamic languages. Recently, Rose described the reasons for proposing JSR-292:
InfoQ previously covered JSR-292 in October as part of the initial announcement for the Da Vinci Virtual Machine Project (MLVM), a test bed for technologies like invokedynamic.
John Rose, who is the specification lead for JSR-292 and primary individual behind the MLVM, has provided regular discussions on his blog with respect to making the JVM more accessible to dynamic languages. Recently, Rose described the reasons for proposing JSR-292:
Later in the same entry, he describes the solution the JSR-292 team is proposing:Why add another invoke bytecode? The answer is that call sites (instances of invoke bytecodes) are useful, and yet the existing formulas for invocation are tied so closely to the Java language that the natural capabilities of the JVM are not fully available to languages that would benefit from them. The key restrictions are:
Dynamic languages implementors expend much time and effort working around these limitations, simulating generic calls in terms of JVM invoke bytecodes constrained by the Java language.
- the receiver type must conform to the resolved type of the call site
- there is no generic way to create adapters around call targets (a corollary of the previous point)
- the call site must link, which means the resolved method always pre-exists
- the symbolic call name is the name of an actual method (a corollary of the previous point)
- argument matching is exact with no implicit coercions (another corollary)
- linkage decisions cannot be reversed (although optimization decisions change, invisibly)
Our solution to these requirements is in three steps. First, we factor out method handles as a simple and generic way of managing methods (arbitrary JVM methods) as units of behavior, which are (as methods should be) directly callable. Second, we define an invokedynamic instruction with one machine word of linkage state, a handle to the call site’s target method. Third, we define a set of core Java APIs for managing linkage state and creating the target method handles for call sites, taking care they these APIs can present the right optimization opportunities to JVMs that wish to exploit them.The announcement of the early draft review kicks off the 90-day review period of the JSR, which will conclude on August 17th, 2008. There are a number ways to stay informed and provide feedback on this JSR as the review period continues:
- Join the JSR-292 Observers list
- Join the JVM Languages group at Google
- Monitor John Rose's blog and the MLVM homepage
