Linkage.registerBootstrapMethod

[Rémi Forax]

John Rose a écrit :
> 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)
>   
yes.
> 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.)
>   

Earlier means between the call to registerBootstrapMethod  and the first 
call
The problem is that registerBootstrapMethod can be anywhere in the code,
I don't see an analysis that can be used by the VM to find where to
call the BSM earlier.

Furthermore, the BSM itself can be a static method of the class containing
the invokedynamic, so the BSM will be able to run without static fields 
correctly initialized ?

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

I see a way to avoid thread race.
The idea is to mandate that registerBootstrap method is always called 
before the initialization
of the static block ends.
In that case, 2 and 3 can be done under the lock used to initialize the 
static block.

In fact, I don't care if 3 is called more than once if it's documented 
in the spec.
But I don't like the fact that a call site created by the BSM is garbaged.
Users may want to maintain a list of call sites (for invalidations?) and 
I don't see
how to do that if step 2 can produce call sites than will not be used.

> -- John
>   
Rémi