On Thu, 17 Jul 2025 05:42:12 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:

>> I think that's right. At first I thought you were referring to the 
>> constructor of the thing that wants to use the cleaner, but you mean the 
>> constructor of the Cleanable itself may be still under construction when the 
>> referent is collected and installing the reachabilityFence at the end of the 
>> constructor prevents that.
>
> I tried to compare how Cleaner and Disposer are used. I found that in most 
> cases Cleaner uses `this` as the object to track. But Disposer often uses a 
> separate object like disposerReferent or some kind of anchor. This patch is 
> one example. In some places we even replaced this with a different object. 
> You can see that in the following RFR:
> https://bugs.openjdk.org/browse/JDK-8030099
> https://mail.openjdk.org/pipermail/swing-dev/2015-October/005053.html
> 
> I think I found the reason: https://bugs.openjdk.org/browse/JDK-8071507
> 
> In older versions of the JDK the Disposer had to use phantom references. 
> Phantom references allow native cleanup to happen after the object is 100% no 
> longer reachable. But this had a problem, the object stayed in memory until 
> the reference was added to the queue and the code called 
> [clear](https://github.com/openjdk/jdk/blob/bc72f476d1281dae2adb2322004c9880c1a6b66c/src/java.desktop/share/classes/sun/java2d/Disposer.java#L134).
> 
> To avoid keeping large AWT or Java2D objects in memory for too long the code 
> used small helper objects as referents instead of using the real object.
> 
> Now the problem described in JDK-8071507 is fixed. So maybe we no longer need 
> to use small disposer referents. And you can check that by the test from the 
> description of this PR.

I know this is possible, but I'd prefer to keep this pattern. This way It is 
crystal clear that nothing to do with reference queues etc are delaying the GC 
from immediately reclaiming the memory.
Honestly, it probably matters not so much for JRSUIControls, and even less so 
for CGraphicsEnvironment, but may matter for some other cases. 

A later follow-up fix could go change a whole bunch of these cases at once and 
we'd then have a good reference (pun intended) as to whether any issues showed 
up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2214335276

Reply via email to