John.Rose at Sun.COM
Sat May 2 18:36:17 PDT 2009
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.
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
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.
More information about the mlvm-dev