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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
