On Tue, 15 Jul 2025 22:34:21 GMT, Phil Race <p...@openjdk.org> wrote:
>> there is even a bug for Cleaner that the reachabilityFence should be moved >> to the end of register: >> https://bugs.openjdk.org/browse/JDK-8291867 >> If there are no objectiosn I'll add it to the Disposer.addRecord in a >> separate bug. > > I think that would be OK, meaning probably harmless. But I don't know if this > case actually requires it. > Where I've seen a problem like this a Java object is used at an earlier point > in the method and not again and so becomes eligible to be freed, but some > native resource it held is needed later but is already freed along with its > no longer references holder. > > Here, if this object (the JRSUIControl) becomes unreachable during > construction, and so the referent and disposer are also unreachable outside > this object, they are still going to be live until we reach code in the > constructor which uses them and since the referent and the disposer are > passed into addRecord they'll be live there until stored. > > But these cases are subtle, maybe I'm missing something. Can you expand on > the scenario ? > Or maybe there's some other patterns where we use Disposer that it is needed ? 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2209047550
