Paul Sandoz paul.sandoz at
Tue Nov 24 18:16:34 UTC 2015

> On 24 Nov 2015, at 18:08, mark.reinhold at wrote:
> 2015/11/24 1:32 -0800, paul.sandoz at
>>> On 24 Nov 2015, at 01:31, mark.reinhold at 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: <>

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

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- 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: <>

More information about the hotspot-compiler-dev mailing list