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