Folks, the 292 EG has decided to register bootstrap methods in the constant
pool, instead of via a call from the <clinit> method.
Here's a summary of constant pool formats as of the latest push to mlvm.
This will require further changes to asm, Mirah, and other bytecode-aware tools.
For now, the JVM accepts both old and new formats of invokedynamic. But old
format support will go away when 292 is finalized.
Best wishes,
-- John
Begin forwarded message:
From: John Rose <john.r.r...@oracle.com>
Date: July 12, 2010 4:20:03 PM PDT
To: jsr-292...@jcp.org
Subject: ISSUE: explicit bootstrap methods (resolution)
...
Here are the constant pool entries defined by JSR 292:
CONSTANT_MethodHandle = 15
u1 RefType ref_type
u2 NameAndType ref_index
enum RefType {
REF_getField = 1,
REF_getStatic = 2,
REF_putField = 3,
REF_putStatic = 4,
REF_invokeVirtual = 5,
REF_invokeStatic = 6,
REF_invokeSpecial = 7,
REF_newInvokeSpecial = 8,
REF_invokeInterface = 9
}
CONSTANT_MethodType = 16
u2 Utf8 signature_index
CONSTANT_InvokeDynamic = 17
u2 MethodHandle bootstrap_method_index
u2 NameAndType name_and_type_index
The format of the invokedynamic instruction is {u1 op = 186; u2
invokedynamic_index; u2 zero}.
The EDR RI has a backward-compatibility mode which (a) allows the Java app. to
call the deprecated methods Linkage.registerBootstrapMethod and (b) allows (but
does not require) the invokedynamic instruction to specify merely a NameAndType
instead of a full InvokeDynamic CP entry. The PFD will not include this mode.
The CONSTANT_InvokeDynamic CP entry does not allow a null bootstrap_method
index.
The call to the BSM specified for a given invokedynamic instruction will be
made as if by invokeGeneric, not invokeExact. This allows direct access to
constructors via REF_newInvokeSpecial, as well more flexible linkage to factory
method calls via REF_invokeStatic. (Other ref-types are not relevant, unless
somebody puts an interesting virtual method on java.lang.Class.)
There seems to be no benefit to defining a default BSM notation in the class
file (e.g., attribute DefaultBootstrapMethod {u2 MethodHandle
default_bootstrap_method_index). Let the constant pool deal with it.
Pack200's column-wise compression will chew up the slack.
Language notes: I expect the Java language support to allow an annotation-like
mechanism to specify the BSM, as a symbolic method reference, for a whole
class, and/or a whole method, and/or a single InvokeDynamic expression. (I
have prototyped this in terms of @BootstrapMethod annotations, but I don't
think this will fly with the language mavens.) Such a notation (if adopted)
will enable refactoring at the source level at two "cut points": First, by
editing the annotation-like syntax for the per-class or per-method defaults,
and second by using a private class-local BSM whose body can be edited at will.
..._______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
