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