[asm] Re: bootstrap methods in the constant pool

[Rémi Forax]

Le 12/08/2010 08:20, John Rose a écrit :
> 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
>    

Wow, you're working in August :)
I've planned to work on ASM after my holidays, in 10 days.

I will create a svn branch with your patches,
I will also add the access modifier tagging a defender method.
The next step will be to add retro support of these items in the backport :)

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

Not that awkward because we can provide an helper visitor (as we do with 
SignatureVisitor) to encode that microlanguage.
Moreover, because more than one invokedynamic will use the same 
bootstrap method, pre-encoding can be a good idea.

But reusing visitMethodInsn with a owner which is not a class or a 
descriptor will break a lot of existing codes.

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

but defender method requires a 1.7 VM and ASM API is 1.3 compatible.

I think that having a new methods for encoding invokedynamic is the best 
way.
It will break all existing codes but this is more user friendly than an 
exception raised
because the owner of visitMethodInsn is not a type anymore.

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

[...]

> -- John
>    

Rémi