Linkage.registerBootstrapMethod

[Rémi Forax]

John Rose a écrit :
> On May 2, 2009, at 4:06 PM, Rémi Forax wrote:
>
>   
>> Hi John, hi all,
>> Doing some testing, I've found that a registerBootstrapMethod that  
>> take
>> the a class
>> that will contain a linkage static method and a method name is  
>> convenient.
>>
>>   public static
>>    void registerBootstrapMethod(Class<?> bootstrapLinkageClass, String
>> name) {
>>        Class callc = Reflection.getCallerClass(2);
>>        MethodHandle bootstrapMethod =
>>            MethodHandles.findStaticFrom(callc, bootstrapLinkageClass,
>> name, BOOTSTRAP_METHOD_TYPE);
>>        if (bootstrapMethod == null)
>>            throw new IllegalArgumentException("cannot find bootstrap
>> method: "+name+" of "+bootstrapLinkageClass);
>>        Linkage.registerBootstrapMethod(callc, bootstrapMethod);
>>    }
>>
>> This avoid to create a MethodHandle in the static init of the class
>> containing an invokedynamic.
>> Also note that a Class like a String is a VM constant.
>>     
>
> That's a nice one, as long as we have bootstrap methods.
>
> But shouldn't we be getting rid of bootstrap methods, along with the  
> target=null state?
>   
I agree about removing the nullcheck, but not about the bootstrap method.

I badly need it.
I want a bootstrap method, a factory method of CallSite because
depending on invokedynamic name I want to store different kind of profile.
I think that one bootstrap method that can return different CallSite 
implementations
allow more freedom.

A stupid example:
public static CallSite createCallSite(...JVMCookies..., Class<?> 
declaringClass, String name) {
  if (name.startsWith("groovy:"))
    return new GroovyCallSite(...JVMCookies...);
  else
    return new GenericCallSite(...JVMCookies..., name);
}

> Then the most natural plug-in cookie will be just a subclass of  
> CallSite, which the JVM will instantiate.
>
> As in:
>    Linkage.registerCallSiteClass(GroovyCallSite.class);
>
> class GroovyCallSite extends CallSite {
>    GroovyCallSite(...JVM cookies go here...) {
>      super(...JVM cookies passed up...);
>      ...more decoding logic here, maybe...
>    }
>    @Override MethodHandle initialTarget() { ... }
> }
>
> What do you think?  The only reason I have hesitated a little is the  
> ugliness of the arguments to the constructor.  (I don't want to invent  
> another little class to hold them, though.)
>   
And what about injecting VM cookies after the creation of the call site.
I will be transparent for the developer.
> -- John
>   
Rémi