Linkage.registerBootstrapMethod

John Rose John.Rose at Sun.COM
Sat May 2 17:19:05 PDT 2009


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?

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

-- John



More information about the mlvm-dev mailing list