JDK-8283660 : Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: javax.naming
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2022-03-24
  • Updated: 2022-06-08
Comments
Three pieces of state are involved with cleaning up AbstractLdapEnumeration: 'enumClnt', 'homeCtx', and 'res'. These pieces of "cleanable state" are mutable - they may be updated through the course of using AbstractLdapEnumeration. Because use-of and cleanup-of an AbstractLdapEnumeration can happen on different threads (the main/program thread, and cleaner thread, respectively), there are potential threading issues that need to be accounted for. Specifically: * Memory Visibility: changes made to the cleanable state on the program thread must be visible to the cleaner thread. Otherwise, cleanup may be performed incorrectly. Concurrency tools (volatile/synchronization/fences/etc) must be used to ensure this cross-thread visibility. * Reachability: it's possible for the VM to deduce that an object is or can become unreachable *while a method on that object is still running*. In the case of an AbstractLdapEnumeration object, once it becomes unreachable, Cleaner is eligible to run the cleaning action (which is not yet unreachable). It's possible that the cleaner thread could clean up the state before the program thread is finished using it. In this case, the program thread would then try to use already-cleaned state. reachabilityFence can be used to keep the AbstractLdapEnumeration object reachable. This ensures that the Cleaner can't clean an object while a method is still running on it (that is, it ensures a level of single-threadedness). This can be considered a general problem for classes that have mutable state that is cleaned up using Cleaner.
08-06-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8311 Date: 2022-04-20 00:32:25 +0000
20-04-2022