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

Peter Levart peter.levart at gmail.com
Fri Dec 18 10:12:51 UTC 2015


Hi,

Now that PhantomReference(s) (excluding sun.misc.Cleaner(s)) are treated 
equally to sun.misc.Cleaner(s), the split between _discoveredPhantomRefs 
and _discoveredCleanerRefs is not needed any more right? Will this be a 
separate simplification?

Regards, Peter

On 12/17/2015 10:30 PM, Kim Barrett wrote:
> On Dec 4, 2015, at 1:07 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Dec 3, 2015, at 6:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>> [Indeed, this whole section isn't strictly necessary; all of it can be
>>>> inferred from information in other places.]
>>> Agree.  This section is no longer necessary and maybe just remove it:
>> I wasn't actually intending to suggest removal.  It seems like there
>> is useful overview information to be had here, rather than requiring
>> readers to make not necessarily obvious inferences.  My impression is
>> that readability is valued more highly than terseness in Java
>> documentation.
> Sorry for the long gap in the discussion.  Mandy and I have been
> talking about what to do about the "Automatically-cleared references"
> section that was the topic of some debate.  We've decided to eliminate
> it, which led us to some additional modifications.
>
> Here's the latest set of webrevs:
> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06/
> http://cr.openjdk.java.net/~kbarrett/8071507/hotspot.06/
>
> They've been rebased to hs-rt tip, which required resolving a minor
> merge conflict with a nearby change to logging in
> referenceProcessor.cpp.  Other than that, there are only specification
> wording changes.  Here's the incremental change from the previous
> version:
> http://cr.openjdk.java.net/~kbarrett/8071507/jdk.06.inc/
>
> We are treating the discussions around changing PhantomReference to
> forbid a null queue as out of scope for this change.  As Mandy said
> earlier, she might propose a separate change for that in the future.
>




More information about the core-libs-dev mailing list