Re: bootstrap methods in the constant pool

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 <[email protected] <mailto:[email protected]>>
> *Date: *July 12, 2010 4:20:03 PM PDT
> *To: *[email protected] <mailto:[email protected]>
> *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
> [email protected]
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws