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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
