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