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
