RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly
vladimir.x.ivanov at oracle.com
Thu Apr 2 16:17:25 UTC 2015
Thanks a lot for the feedback!
> 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)
> 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/CallSiteDepContextTest.java); and
(2) artificially stressed the logic by eagerly initializing the 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, yet.
> Can a call site target class change as a result of LF recompiling or customization?
> 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
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.
More information about the core-libs-dev