On invoke dynamic and method handles

[John Rose]

On Dec 17, 2008, at 12:13 PM, Rémi Forax wrote:

> Iulian Dragos a écrit :
>> I noticed several differences between what JSR 292
>> (http://jcp.org/en/jsr/detail?id=292) says and the current
>> implementation. I know this is work in progress, but at least one
>> difference seems small enough to be an oversight.

Iulian:  I'm very glad you are looking at the spec. and HotSpot  
implementation, and I apologize for the incomplete state of both.   
It's going to get better soon.

The most recent version of JVM specs. (headed for HotSpot integration  
RSN) is here for engineering review:
   http://webrev.invokedynamic.info/jrose/6655638.meth/

That review copy is changing also; it's now a month old.

> Currently, the first draft of the spec is outdated
> and the implemntation is not up to date too.

That's right, Remi.  I'm working furiously on both spec. and implem.  
furiously, aiming to get a refresh of both by Christmas.

Until engineering and JSR 292 Expert Group reviews are complete, both  
are moving targets, of course.  But Remi is correct on all points.

> The current idea is to implement invokedynamic like invokestatic,
> i.e without a receiver.

This was the outcome of Summit conversations; I initially resisted  
this but then flip-flopped after realizing the community has plenty  
of months to adjust to a new instruction, and many more years to  
regret a design compromise on that point.

The new instruction is (almost certainly) going to use the previously- 
unused bytecode point 0xba, will be a five-byte format with a two- 
byte CONSTANT_NameAndType index followed by two MBZ padding bytes  
(for possible interpreter use).  The type Dynamic (charming as it is)  
does not play a role in the bytecodes.

The langtools branch of the mlvm repo. has a trial version of javac  
(meth.patch) that emits a couple of different syntaxes of  
invokedynamic.  The next rev. will remove the unused syntaxes.

There is a provisional syntax for issuing invokedynamic calls from  
Java that looks like a call to a static method on the interface Dynamic:
   java.dyn.Dynamic.<boolean>foo((int)x, (char[])y, (Object)z);
   // invokedynamic foo(I[CLjava/lang/Object;)Z

To generate a method handle calls, just issue a virtual call to  
'invoke' with an arbitrary signature.  The polymorphic signature  
requires another small javac change; the invoke method appears to be  
parameterized by the method return type, as with invokedynamic.

See:
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt  
(watch typo:  type param is after dot)
   http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.patch

>> The contract of 'bootstrap' is that it makes the call and returns a
>> value, possibly setting a target for future calls. In the current
>> implementation, one would have to create a new array and strip the
>> first element:
>>
>> cs.setTarget(mh);
>> Object[] args1 = new Object[args.length - 1];
>> System.arraycopy(args, 1, args1, 0, args.length - 1);
>> return rm.invoke(args[0], args1);
>>
>> I find this to be a typical scenario, so I wonder why this deviation
>> from the JSR.

It never made perfect sense to do things this way, because many dyn.  
langs. (see Groovy) use static methods as units of pluggable  
behavior.  But it was that way because the syntax for invokedynamic  
was receiver-based.  Now it is completely symmetric in all arguments.

> You can directly call a MethodHandle without put object in a array
> by calling a invoke method with any arguments you want:
> MethodHandle mh=...
> mh.invoke(3,"foo");     // here 3 is not boxed

You may also prefer to write signature-polymorphic code.  (Write  
once, run every case more slowly.)  To support this, the newest spec  
for method handles has a "varargs" bit on MethodType and appropriate  
adapter constructors.  So it's easy to spread or gather argument  
groups, independently of the reflective API, or in concert with it.

Best wishes,
-- John