Re: Re: Re: bootstrap methods in the constant pool

Hi Eugene,

Le 13/07/2010 14:39, Eugene Kuleshov a écrit :
>
>  Perhaps we could split it into two visit calls...

yes, but in that case we loose backward compatibility.

> or introduce a micro language, e.g. in desc field.

you mean in owner field, invokedynamic has no owner.

>  BTW, what would be the meaning of bootstrap method pointing to a 
> method handle of get/putField or get/putStatic type?

This is not allowed.

>
>  An alternative way to represent bootstrap method in the bytecode 
> could be to introduce a new attribute at the class, method and code 
> level. This would be also closer to semantic John is suggesting. 
> Though that way you couldn't enforce constrains on a pretense of the 
> bootstrap methods, but that can be done in the verifier.

This is not the way chosen by the JSR 292 expert group,
and creating of fake attribute will trouble ASM users.

In my opinion, the only valid path is to introduce a new method
visitInvokeDynamicMethodInsn(int refType, String boostrapOwner, String 
bootstrapName, String bootstrapDesc, String invokedynamicName, String 
invokeDynamicDesc)

>
>  regards,
>  Eugene

kind regards,
Rémi

>
>
> Rémi Forax wrote:
>> 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