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