I just posted a prototype patch for local BSMs which works on my unit tests.
http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/asm There is also an updated "ldc" patch. I've put the patches with some good examples here: http://cr.openjdk.java.net/~jrose/pres/asm-jsr292-examples.zip On Jul 13, 2010, at 5:39 AM, Eugene Kuleshov wrote: > Perhaps we could split it into two visit calls... or introduce a micro > language, e.g. in desc field. I handled the extra degrees of freedom for indy instructions by replacing the "class" string (of a normal invokeinterface) with a microlanguage (distinct from valid class names). The microlanguage shows up in places like this: INVOKEDYNAMIC invokeStatic.meth/IndyLocalBootstrap$FancySite.make.(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;)Ljava/dyn/CallSite;.foo3 ()Ljava/lang/Object; Everything before the "foo3" is a reference to the BSM. Awkward but workable. When we do new instructions, the MethodVisitor needs new methods. This would be a good application for "defender methods". A weak substitute would be a V2 interface which extends the V1 interface, and a default implementation of the new methods (as a static method) in an associated V2 implementation module. > BTW, what would be the meaning of bootstrap method pointing to a method > handle of get/putField or get/putStatic type? The JVM would reject it at run time (not verify time) because the thing can't have the signature of a real BSM. Only invokestatic and newInvokespecial make interesting BSMs. But, both do, so there's a reasonable exercise of the CONSTANT_MethodHandle data 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. I think such a design is inadequate for code weaving applications. A code weaver is not likely to want the same BSM as the pre-existing invokedynamic instructions, but it may want to weave new instructions between the old ones. I think this may be a good way to make AOT work: You pre-inject your cut points as indy instructions, which link immediately to (cheap) no-ops. When you want to dynamically vary a cut-point, you relink the affected indy instructions. This clearly uses a different BSM than any pre-existing BSM used by the original compiler. -- John > 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
