Per cu.

~~~

To reproduce the problem:

Save attached file "A.java" at location: /data/tmp/testleak/lib/A.java
Save attached "TestClassloaderLeak.java" at location: /data/tmp/testleak/TestClassLoaderLeak.java
Run attached script "

testleak.sh

", adjust hard-coded JDK installation locations.

Observe that no classes are unloaded with Java 21 but classes are unloaded with Java 17.

We have bisected to this commit, which causes the difference in behavior:

https://github.com/openjdk/jdk19u/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb

In memory snapshots, we see that a ProtectionDomain is holding the class loader in question. The ProtectionDomain belongs to a thread of a ForkJoinPool. We tried submitting a task in ForkJoinPool at the start of our application, that didn't help. Possibly the leak is caused by any new thread used in the pool (see the static initializer of ForkJoinWorkerThread).

Please advise us how to workaround the issue.

The structure of our application is roughly, the user changes classes then runs their code in our framework. We have a dedicated classloader for the user classes, we unload previous versions of user classes, then use a new classloader to load the new versions and run the user code. We use the same JDK to do so, we also hot swap when the user is in a debug session, changing their code. We need something to avoid the ProtectionDomain that causes the classloader to be leaked.

Define the value or impact to you or the business
We see both performance and functional problems due to the leak, the impact is high.

Where are you experiencing this behavior? What environment?
When using OpenJDK 21.0.2+13.

~~~

Kindly share your ideas.