Le 13/07/2010 04:59, John Rose a écrit :
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.
The biggest problem of this change is that at first look it requires an
incompatible
change of current ASM instruction visitor.
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
cheers,
Rémi
Begin forwarded message:
*From: *John Rose <john.r.r...@oracle.com <mailto:john.r.r...@oracle.com>>
*Date: *July 12, 2010 4:20:03 PM PDT
*To: *jsr-292...@jcp.org <mailto: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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
