Reference.reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Fri Dec 11 15:52:58 UTC 2015


Hi Paul,

No objections, but just wanted to summarize a couple of possible key
performance issues that were raised on the concurrency-interest thread.
You may have picked them up already, so pardon the repetition:

1) current impl/prototype is purposely barred from inlining - this will be
a compiler optimization fence, particularly bad in loops

2) the expected "try { ... use(r) ... } finally  { reachabilityFence(r); }"
idiom will significantly increase bytecode size, possibly impacting
inlining.

I'm sure you guys will address this in the end, but just wanted to
reiterate those just in case :).

Thanks

sent from my phone
On Dec 11, 2015 4:37 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:

> Unless any strong objections are raised I plan to push the latest path on
> Monday.
>
> >
> > Updated:
> >
> >
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html
> <
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/src/java.base/share/classes/java/lang/ref/Reference.java.sdiff.html
> >
> >
> > I think there is an opportunity to add further examples, but i would
> like to take a swing at that later on.
> >
> >
> >> - I now agree with you and Doug about calling this a "fence".  Can we
> >>   just name it "fence" rather than the wordier "reachabilityFence"?
> >>   Looking at a typical invocation,
> >>
> >>       Reference.reachabilityFence();
> >>
> >>   seems a bit redundant while
> >>
> >>       Reference.fence();
> >>
> >>   reads quite nicely.  Is there, or will there ever be, any other kind
> >>   of reference-related fence?
> >>
> >
> > I doubt there will be another kind of reference fence, but it could be
> used in conjunction with other memory fences (currently on VarHandles) and
> if static imports are used it might look rather out of place as to what
> fence “fence” actually refers to. That is why i prefer the longer more
> descriptive name.
> >
> > Paul.
>
>



More information about the core-libs-dev mailing list