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 <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
