Thanks a lot for the feedback!
Question: How common is state 2 (context-free CS) compared to state 3
It's quite rare (<2%). For Box2D the stats are:
total # of call sites instantiated: 22000
(1): ~1800 (stay uninitialized)
No, it's not. But: (1) I wrote a focused test on different context state
transitions (see test/compiler/jsr292/CallSiteDepContextTest.java); and
(2) artificially stressed the logic by eagerly initializing the context
And is state 2 well tested by Box2D?
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
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,
Good point! It's definitely a problem I haven't envisioned. Ok, I
completely removed call site target class logic and use DefaultContext
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?
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.
mlvm-dev mailing list