blog post on invokedynamic

[John Rose]

On Feb 17, 2009, at 2:05 AM, Rémi Forax wrote:

> I've noticed that you don't say how the bootstrap method is found  
> from a
> call site.

Shh!  :-)  It is in the NetBeans project associated with the blog  
entry, but it didn't make the cut into the blog entry.

The fuller code is:

     // Set up a class-local bootstrap method.
     static {
         MethodType bootstrapType = MethodType.make(Object.class,  
CallSite.class, Object[].class);
         MethodHandle bootstrapDynamic
             = MethodHandles.findStatic(GetNameDemo.class,  
"bootstrapDynamic", bootstrapType);
         Linkage.registerBootstrapMethod(GetNameDemo.class,  
bootstrapDynamic);
     }
     private static Object bootstrapDynamic(CallSite site, Object...  
args) {
         MethodHandle target = linkDynamic(site);
         site.setTarget(target);
         return MethodHandles.invoke_1(target, site, args);
     }

(Oops!  I just refreshed the upload, which had a stale version.)

> You use an analogy, in Java there are differents method invocation  
> semantics,
> why not let the other language specify different kind of method
> invocation semantics by allowing different bootstrap methods.

That's clever.  I don't think we need to do that; here are my thoughts:

Most JVMs should be able to parse this reasonably well.  Some might  
have trouble with the strange placement of the second CP reference.

(Dis-)assemblers of various sorts would have to deal with the oddity  
that there are 2 CP references in the instruction.  I know cases where  
this would require work.

 From the MOP point of view, this would allow each call site to go  
into the mop through its own entry point, as if each call site were a  
different language.  That would make language embedding or mixing (in  
the same module) much simpler.

 From the Java language point of view, you'd have to write something  
much uglier like:
   Dynamic.<String, myDynamicBootstrap>getFile(myfile)
or
   Dynamic.<String>getFile(myDynamicBootstrap, myfile)

On the other hand, if you have the current design for a per-class  
bootstrap handler, you can easily simulate the per-call-site handler,  
simply by prepending an integer to every method name, using it in a  
switch statement in the class-local bootstrap handler to select the  
specific "real' bootstrap handler, and stripping off the integer.

Hmmm; you would have to forge a call site with the amended name...   
The class CallSite is in fact designed for this.  (That would work  
slightly better if it were an interface, but the EG settled on a  
concrete class for VM reasons.)

A MOP will have to have conventions for structuring method names; such  
conventions can also be used to select MOP entry points.  (I'm  
thinking of URL prefixes as an analogy:  "javascript:getName",  
"java:getName", "special:getName", etc.)

In the end, I think a class-specific bootstrap method is easier to use  
in the common case and allows efficient simulation of the uncommon case.

-- John