John, Peter,

Thanks a lot for the feedback!

Updated webrev:

Question:  How common is state 2 (context-free CS) compared to state 3 
(indy-bound CS)?
It's quite rare (<2%). For Box2D the stats are:
   total # of call sites instantiated: 22000
   (1): ~1800 (stay uninitialized)
   (2): ~19900
   (3): ~300

And is state 2 well tested by Box2D?
No, it's not. But: (1) I wrote a focused test on different context state transitions (see test/compiler/jsr292/; and (2) artificially stressed the logic by eagerly initializing the context to DEFAULT_CONTEXT.

I had (2)->(3) transition (DEF_CTX => bound Class context) at some point, but decided to get rid of it. IMO the price of recompilation (recorded dependencies should be invalidated during context migration) is too much for reduced number of dependencies enumerated.

I recommend putting CONTEXT_OFFSET into CallSite, not the nested class.
For one thing, your getDeclaredField call will fail (I think) with a security 
manager installed.
You can load it up where TARGET_OFFSET is initialized.
Since I removed DependencyContext, I moved CONTEXT_OFFSET to CallSite.

BTW why do you think security manager was the problem? (1) Class.getDeclaredField() is caller-sensitive; and (2) DependencyContext was eagerly initialized with CallSite (see UNSAFE.ensureClassInitialized() in original version).

I haven't looked at the JVM changes yet, and I don't understand the cleaner, 

Can a call site target class change as a result of LF recompiling or 
If so, won't that cause a risk of dropped dependencies?
Good point! It's definitely a problem I haven't envisioned. Ok, I completely removed call site target class logic and use DefaultContext class instead.

On 4/2/15 11:02 AM, Peter Levart wrote:> Hi Vladimir,
> Would it be possible for CallSite.context to hold the Cleaner instance
> itself (without indirection through DependencyContext)?
> DEFAULT_CONTEXT would then be a Cleaner instance that references some
> "default" Class object (for example DefaultContext.class that serves no
> other purpose).
Good idea! I eliminated the indirection as you suggest.

Best regards,
Vladimir Ivanov
mlvm-dev mailing list

Reply via email to