RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

[Roger Riggs]

+1 on the change as a whole.

Editorially, I agree that paragraph in the package-info obscures the 
point its trying to make.
Your suggestion is clearer.

Roger



On 12/03/2015 08:01 AM, Peter Levart wrote:
> Hi Kim,
>
> Kudos for finding an observable change in behavior. Although the 
> specification could also be read in a way so that this would not be 
> observable. Originally it states:
>
> "Unlike soft and weak references, phantom references are not 
> automatically cleared by the garbage collector as they are enqueued. 
> *An object that is reachable via phantom references will remain so* 
> until all such references are cleared or themselves become unreachable."
>
> I read this as: "... An object that is reachable via phantom 
> references will remain phantom reachable ..."
>
> If phantom-reachable objects have links among them, this doesn't make 
> them strongly reachable.
>
> So I would argue that when both roots to O1 and O2 (in the test) are 
> finally removed, O1 and O2 should be considered phantom-reachable, 
> regardless of the link from O1 -> O2. When root to O2 is removed 
> before the 2nd GC round, P2 should be notified as O2 transitions from 
> reachable -> phantom reachable. This is no different from the 
> situation when both roots to O1 and O2 are removed at the same time 
> before a GC round: both P1 and P2 are notified.
>
> Anyway, this change is good. I would only rephrase this statement in 
> package-info.java a bit:
>
>   96  * Soft and weak references are automatically cleared by the 
> collector
>   97  * before being added to the queues with which they are 
> registered, if any,
>   98  * hence they need not be registered with a queue in order to be 
> useful.
>   99  * Phantom references, by contrast, do not allow their referents 
> to be
>  100  * retrieved, so they must be registered with a queue.
>
> Perhaps to something like:
>
> Soft, weak and phantom references are automatically cleared by the 
> collector before being added to the queues with which they are 
> registered, if any. While Soft and weak references allow access to the 
> referent before they are cleared, and hence need not be registered 
> with a queue in order to be useful, Phantom references prevent access 
> to the referent and are only useful when registered with a queue.
>
>
>
> Regards, Peter
>
> On 12/02/2015 07:37 PM, Kim Barrett wrote:
>> Please review this change to PhantomReference processing, changing the
>> GC-based notification to automatically clear the referent.
>>
>> This change provides performance benefits by eliminating the work
>> involved in keeping the otherwise inaccessible referent objects alive,
>> as required by the existing specification. This not only immediately
>> removes some work, but may enable further performance improvements.
>> It also allows the referent objects to be immediately reclaimed in
>> the GC cycle in which they were determined to be inaccessible, rather
>> than lingering as a form of floating garbage until the application
>> deals with the notified reference.
>>
>> This change results in a behavioral change to application code, as
>> demonstrated by the associated test.  Under the old specification, a
>> reference R with referent X may be kept alive because it is referenced
>> by an otherwise inaccessible referent Y of phantom reference P. This
>> will result in X being treated as strongly referenced and prevent R
>> from being notified, even if R is a phantom reference and X has become
>> inaccessible to the application.  With this change, Y is reclaimed
>> when it becomes inaccessible and P is notified, and no longer prevents
>> X from itself becoming a candidate for reclaimation once it is no
>> longer accessible to the application.  While this is a change in
>> behavior, it seems unlikely to affect applications negatively.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8071507
>>
>> Webrevs:
>> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.05/
>> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.05/
>>
>> Testing:
>> jprt, aurora ad hoc (defaults, GC/Runtime nightly, JCK)
>>
>