RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java [v4]

[Sergey Bylokhov]

On Wed, 16 Jul 2025 21:00:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> I think I understand why reachabilityFence is used [here](https://github.com/openjdk/jdk/blob/a5c9bc70324693e9d0b25bb2c51b91dfc750c453/src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java#L84). That code first registers the object in the cleanup queue and then continues executing the rest of the constructor. As far as I understand, the object could be collected between the registration and the end of the constructor so the cleaner will be called on a partially constructed object.
>> 
>> If that assumption is correct then in the change above the code:
>>         nativeMap = new HashMap<Key, DoubleValue>();
>>         changes = new HashMap<Key, DoubleValue>();
>> might never be executed and the native disposer will be called before, not an issue in this particular case but good to know.
>> Or I missing something.
>
> 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.

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

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