[9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

[Vladimir Ivanov]

John, Peter,

Thanks a lot for the feedback!

Updated webrev:
   http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/hotspot/
   http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/jdk/

> 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/CallSiteDepContextTest.java); 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, 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 
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