forax at univ-mlv.fr
Mon May 4 04:27:26 PDT 2009
Rémi Forax a écrit :
> 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
>>> I think that one bootstrap method that can return different CallSite
>>> 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.)
> Earlier means between the call to registerBootstrapMethod and the first
> 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
>> 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
>> 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.
Answering to myself:
the problem of doing 3) at the end of the static block is that this disallow
to use invokedynamic in the static block.
It appears to me that this is a too strong restriction.
Perhaps we could rely on an explicit call ?
Something like :
that sould be executed by the static block and only once.
>> -- John
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev