hg: mlvm/mlvm/langtools: meth: support transitional and native forms of invokedynamic in javac and javap

[John Rose]

On Oct 9, 2008, at 12:51 AM, Rémi Forax wrote:

> hum, it seems invokedynamic as now three encodings ?
> - invokedynamic (bytecode 186) which works like invokestatic
> - invokeinterface (like in JSR292 current spec)
> - invokestatic(on java/lang/Dynamic) i suppose.
>
> As the backport implementer, I don't understand why we need two
> way invokeinterface/invokestatic to emulate invokedynamic ?

That's not part of the spec. yet.  The javac stuff is highly  
experimental.

But I'm working on a post-EDR spec.  The 'invokestatic' form is in  
response to various comments about defects in the EDR design.

You and I and others were talking at the Summit about different  
possible representations for invokedynamic, and the trade-offs  
between a verifier-breaking representation "native" bytecode and a  
more compatible overloading of invokeinterface (in the EDR) or  
invokestatic.

Remember that Fredrik Öhrström was objecting on philosophical grounds  
to using a receiver-based instruction for a receiverless semantics.   
This mismatch causes several problems, which I have noticed people  
stumbling over repeatedly, and I want us to fix it if we can.

I think now (and would like your comments on this) that we should  
have a transitional (tool-friendly) encoding and a final  
"native" (tool-breaking) encoding.  The transitional encoding would  
be deprecated on final release, and is for use in 2008-2009, while  
tools have not yet updated to all the JDK 7 specs.

Given this strategy, we can give up the EDR invokeinterface-based  
encoding (which has flaws in its static typing due to the receiver- 
based format) and use invokestatic.  Although invokestatic has a too- 
short opcode size, this doesn't matter for a transitional form, if we  
know we are going to settle on a 5-byte invokedynamic instruction.   
(Size matters for the sake of some interpreter-based JVM  
implementations, since each invokedynamic instruction requires its  
own runtime linkage resources, unlike the other invokes.)

The typing and treatment of the implicit receiver argument of  
invokeinterface has confused people who are trying to implement and  
understand the EDR spec.  (I think the main problem in the IKVM  
version had to do with an off-by-one in the signature, right?)   
Perhaps the EDR spec. could have been better, but this is a real land- 
mine in the design, and if we have the opportunity to fix it, we  
should.  The fix will require going to a "native" invokedynamic,  
using the 186 bytecode-point, but we have plenty of time to do it, so  
we should.

The point of putting all three into javac is to to allow (or not to  
impede) experimentation with all currently-live possibilities.  As  
soon as the EG decides what to do (which I hope will be soon), we can  
delete one or two of the options from javac and from everything else.

So the short answer to your original question is, we don't need both,  
as soon as the EG makes a decision.  The reason you are seeing both  
is that I am letting the RI and the EG discussions unfold in  
parallel, as much as possible.  (Welcome to the bleeding edge!  :-)

Thanks for asking!

-- John