<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 Nov 2015, at 18:08, <a href="mailto:mark.reinhold@oracle.com" class="">mark.reinhold@oracle.com</a> wrote:</div><br class="Apple-interchange-newline"><div class="">2015/11/24 1:32 -0800, <a href="mailto:paul.sandoz@oracle.com" class="">paul.sandoz@oracle.com</a>:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 24 Nov 2015, at 01:31, <a href="mailto:mark.reinhold@oracle.com" class="">mark.reinhold@oracle.com</a> wrote:<br class="">This seems eminently reasonable, but why does it belong in the<br class="">java.lang.ref.Reference class?  It has nothing (directly) to do<br class="">with reference objects.<br class=""><br class="">java.lang.Runtime, perhaps?<br class=""></blockquote><br class="">Out of all the places i thought Reference was the least indirect. The<br class="">method documentation refers to the notion of "strongly reachable” in<br class="">the j.l.ref package doc (I should update to link directly to that). In<br class="">effect it’s an operation on potential referents that relates to<br class="">reachability, garbage collection and finalization.<br class=""><br class="">A further weaker argument is Reference is not commonly used thus there<br class="">may be less chance of this method being misused.<br class=""><br class="">I do prefer the current location, but i don’t strongly object to<br class="">moving it to Runtime.<br class=""></blockquote><br class="">Having read through more of the background, I now agree that the<br class="">Reference class is a suitable home for this method.  Most anyone who<br class="">needs this method will already be thinking about finalization and/or<br class="">reference objects.<br class=""><br class="">I do think "keepAlive" is a better name, especially since there are<br class="">(at present) no other "*Fence" methods in sight.<br class=""><br class=""></div></blockquote><div><br class=""></div></div><div>The current name was considered less open to misinterpretation (see Doug’s latest email).</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">A few more questions/suggestions:<br class=""><br class="">  - This method started out (way back in 2009, on concurrency-interest)<br class="">    as part of a more general java.util.concurrent.Fences class [1].<br class=""></div></blockquote><div><br class=""></div>And it goes back even earlier (hat tip to Peter Kessler) under the “keepAlive” name:</div><div><br class=""></div><div>  <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1256.html" class="">http://www.cs.umd.edu/~pugh/java/memoryModel/archive/1256.html</a></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">    Do we have any expectation that Fences will ever be proposed for<br class="">    inclusion in the platform, or is it something that's otherwise<br class="">    abandoned?<br class=""><br class=""></div></blockquote><div><br class=""></div><div>They are subsumed under the VarHandle JEP and for now are tacked on to the VarHandle class:</div><div><br class=""></div><div><a href="http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/b36071eb5637/src/java.base/share/classes/java/lang/invoke/VarHandle.java#l163" class="">http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/b36071eb5637/src/java.base/share/classes/java/lang/invoke/VarHandle.java#l163</a></div><div><br class=""></div><div><a href="http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/b36071eb5637/src/java.base/share/classes/java/lang/invoke/VarHandle.java#l1436" class="">http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/b36071eb5637/src/java.base/share/classes/java/lang/invoke/VarHandle.java#l1436</a></div><div><br class=""></div><div>It was felt that these memory ordering fences are so very different from the reachability fence they be kept separate.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="">  - The specification, while short, needs some work.  As far as I can<br class="">    tell the scope of the guarantee made by this method does not extend<br class="">    beyond that of the method that invokes it</div></blockquote><div><br class=""></div><div>Yes, and more specifically beyond the actual invocation from within the method that invokes it.</div></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">, yet the specification<br class="">    says "regardless of any prior actions of the program", which is<br class="">    almost certainly too broad.<br class=""><br class=""></div></blockquote><div><br class=""></div><div>Hmm… perhaps we can say something like “regardless of any prior actions of the calling method”? I am not sure that is entirely accurate if say the calling method gets inlined (and say the reference is passed down from another method).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="">  - Is it worth including one or both of the examples from the original<br class="">    Fences draft?<br class=""><br class=""></div></blockquote><div><br class=""></div>I think so.</div><div><br class=""></div><div>Paul.</div></body></html>