bootstrap methods in the constant pool

[John Rose]

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.rose at oracle.com>
Date: July 12, 2010 4:20:03 PM PDT
To: jsr-292-eg at 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.

...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100712/4039f2aa/attachment.html