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

[Rémi Forax]

John Rose a écrit :
> 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.)
>   
I see another way to encode invokedynamic using the existing opcodes.
The idea is to use invokeinterface but to mandate that the receiver must 
be null.
So invokedynamic m(a,b,c) should be encoded
a_const_null
....
invokeinterface Dynamic.m(a,b,c)
and the null receiver should be drop before calling the method handle.

With this encoding, you have a receiveless 5-byte opcode.
> 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?)   
>   
yes.
> 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. 
Totally agree.
>  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.
>   
ok, I understand now.
> 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
>   
Rémi