Re: Re: bootstrap methods in the constant pool

  Perhaps we could split it into two visit calls... or introduce a micro 
language, e.g. in desc field.
  BTW, what would be the meaning of bootstrap method pointing to a 
method handle of get/putField or get/putStatic type?

  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.

  regards,
  Eugene
 

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