Reference.reachabilityFence
Vitaly Davidovich
vitalyd at gmail.com
Tue Nov 24 13:00:23 UTC 2015
One can look at reachabilityFence in same light as requesting gc or
finalization, both of which live in Runtime.
sent from my phone
On Nov 24, 2015 7:54 AM, "David Holmes" <david.holmes at oracle.com> wrote:
> On 24/11/2015 7:32 PM, Paul Sandoz wrote:
>
>>
>> On 24 Nov 2015, at 01:31, mark.reinhold at oracle.com wrote:
>>>
>>> 2015/11/23 8:38 -0800, paul.sandoz at oracle.com:
>>>
>>>> Please review the addition of Reference.reachabilityFence contributed
>>>> by Aleksey, Doug and myself:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/
>>>>
>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-hotspot/webrev/
>>>>
>>>
>>> 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.
>>
>
> As all Runtime methods are instance methods the usage here would be a bit
> awkward. Personally I thought reference was a very suitable location for a
> reachability-related method.
>
> Cheers,
> David
>
> Paul.
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151124/b2793360/attachment.html>
More information about the hotspot-compiler-dev
mailing list