Reference.reachabilityFence

[Paul Sandoz]

> On 24 Nov 2015, at 18:08, mark.reinhold at oracle.com wrote:
> 
> 2015/11/24 1:32 -0800, paul.sandoz at oracle.com:
>>> On 24 Nov 2015, at 01:31, mark.reinhold at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151124/acf78622/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151124/acf78622/signature.asc>