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.san...@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.
>
>
