Linkage.registerBootstrapMethod

[John Rose]

On May 2, 2009, at 5:55 PM, Rémi Forax wrote:

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

D'oh!  Thanks.

Indeed, factories are strictly more powerful than classes.

So will this work for you?

   bootstrap-method : method handle = lambda(callsite symbolic info)  
=> (result : CallSite)

I think the bootstrap method should not be required to perform any  
side-effects on the call site; that should be a separate step in the  
call-site life cycle, embodied in a method.  Did we say the bootstrap  
method might be allowed to run earlier than the first call, for more  
eager creation of call sites? (For code prelinking of some sort, not  
yet invented.)

Then the steps are:

1. prepare bytecodes & (virtually) allocate target variables,  
initialized to null (unlinked state)

2. (before or upon first invocation) call bootstrap method to  
permanently create CallSite (the JVM may throw an error if BSM hands  
it a CallSite already attached to a call: this implies invisible JVM  
cookies are in there somewhere)

3. at the "first call" (precisely, to an unlinked call site), do  
CallSite.initialize (which must link the site, else error)

4. at every call, pick up the non-null target, and just jump through it

5. once a target is set non-null, it can never go null again, except  
(perhaps?) at a safepoint as a result of bulk unlinking

A call site is unlinked if and only if its target method is null.  And  
setTarget(null) is always rejected.

As it is currently coded, steps 2 and 3 might happen several times,  
either by racing threads as with the other invoke bytecodes, or in  
this case via re-entrant execution (probably a user error, but maybe  
not!).

Yes, racing threads can redundantly link, but the process is all one- 
way, monotonic, so it completes.  And it doesn't run bytecodes, except  
to load classes, which serializes through a system dictionary lock.   
For the interpreter linkage logic, see the hotspot sources, routine  
InterpreterRuntime::resolve_invoke.

The odd thing with 292 is that, because we are using upcalls that run  
Java code, the application code (the MOP) can witness the races as  
they occur.  We could serialize those events, with some care to avoid  
DOS attacks and unintentional interference between unrelated code.   
Sounds like more trouble that it's worth.  The JVM can promise to pick  
a winner and commit at most one CallSite object per bytecoded call  
site.  I suppose that's an issue for the EG to worry about.

-- John