hg: mlvm/mlvm/langtools: meth: support transitional and native forms of invokedynamic in javac and javap
John.Rose at Sun.COM
Thu Oct 9 10:26:48 PDT 2008
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
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
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
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!
More information about the mlvm-dev