I believe that the IBM side of this process is now complete and Oracle should have email communications (as of September 18th) from IBM that confirms my coverage under IBMs agreement with Oracle.
Is there anything I should be doing at this point to get this unblocked within the Oracle/OpenJDK machine so that we can move forward with the review of this change? Thanks, CHris On Tue, 22 Jul 2025 at 19:00, Chris Dennis <chris.w.den...@gmail.com> wrote: > Is there a process I can (or should?) be following to get my PR for fixing > this through OCA verification, or do I just need to be a little more > patient? > > Thanks, > > Chris > > On Tue, 15 Jul 2025 at 07:59, Chris Dennis <chris.w.den...@gmail.com> > wrote: > >> Apologies, that description is pretty lousy. A more explicit description >> of the leak (the one in my test in >> https://github.com/openjdk/jdk/pull/26296) would be: A class loaded by >> classloader 'C' statically references an Executor created via >> newSingleThreadExecutor(threadFactory). The ThreadFactory is an instance of >> a class also loaded by 'C'. This executor is then shutdown via >> shutdownNow(). The resulting structure will pin the classloader 'C' in >> memory. >> >> Chris >> >> On Tue, 15 Jul 2025 at 06:50, Alan Bateman <alan.bate...@oracle.com> >> wrote: >> >>> On 11/07/2025 15:42, Chris Dennis wrote: >>> > Hi All, >>> > >>> > I believe I've identified a bug in >>> > Executors.AutoShutdownDelegatedExecutorService that can trigger a >>> > classloader leak even in the presence of "correct" Executor >>> > lifecycling. AutoShutdownDelegatedExecutorService only unlinks the >>> > PhantomReference used for cleanup handling when it is shutdown via the >>> > shutdown() method. If an Executor wrapped in this way is instead >>> > shutdown using the shutdownNow() method and it references a >>> > classloader via an injected attribute: ThreadFactory, AbortPolicy, >>> > etc. then the cleanup action will reference the classloader, and the >>> > classloader will remain strongly referenced. Adding an additional >>> > override as shown in the attached patch is sufficient to fix the leak >>> > in my testing. >>> > >>> It would be useful if you could say more about the scenario. The cleaner >>> should execute once the executor service is eligible to be GC'ed and the >>> reference is queued. Invoking shutdown just means it is early >>> unregistered. So I'm wondering if your issue is more about timing in >>> that it's not being GC'ed in a timely manner. >>> >>> -Alan >>> >>
