JDK-8327501 : Common ForkJoinPool prevents class unloading in some cases
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 19,21,22
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2024-03-06
  • Updated: 2024-11-25
  • Resolved: 2024-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22 JDK 23
21.0.5Fixed 22.0.2Fixed 23 b14Fixed
Related Reports
Relates :  
JDK-8344993 - [21u] [REDO] Backport JDK-8327501 and JDK-8328366 to JDK 21
Relates :  
JDK-8341989 - [21u] Back out JDK-8327501 and JDK-8328366
Relates :  
JDK-8328366 - Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501
Relates :  
JDK-8277090 - jsr166 refresh for jdk19
Description
When the ForkJoinPool.commonPool() creates new worker threads, they capture an AccessControlContext from the location where they were created, which means that the class won't get unloaded for the lifetime of that worker thread.
Comments
Note on OpenJDK 21 backport: The JDK 21 backport got backed out from the 21.0.5 release with JDK-8341989.
16-10-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/338 Date: 2024-03-07 10:07:27 +0000
09-07-2024
[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Fixes the class unloading regression since JDK 19. Applies cleanly. Tests pass, but there is a regression, which is fixed by JDK-8328366. Risk is medium: affects common paths, has bugtail with easily detectable failures.
31-05-2024
[jdk22u-fix-request] Approval Request from Aleksey Shipilëv Fixes the class unloading regression since JDK 19. Applies cleanly. Tests pass, but there is a regression, which is fixed by JDK-8328366. Risk is medium: affects common paths, has bugtail with easily detectable failures. Doing this patch in 22.0.2 exposes the fix to larger group of users, paving the way to 21u backport.
27-05-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/206 Date: 2024-05-15 09:32:31 +0000
15-05-2024
OK. Created JDK-8328366 in order to get this fixed.
18-03-2024
[~sgehwolf] I don't think one was created yet, so yes, please go ahead and create one.
18-03-2024
[~alanb] [~vklang] Is there a bug tracking this CCL compatibility issue introduced with this fix? Shall I file one?
18-03-2024
https://github.com/quarkusio/quarkus/issues/39526 has steps how to reproduce the setContextClassLoader() compatibility issue in the wild.
18-03-2024
Discussed this with [~alanb] just now and he thinks he has a solution for the unloading AND the CCL issue.
14-03-2024
[~alanb] Agreed. Given that the situation only occurs in the absence of a security manager I think we should have enough room to find a suitable alternative solution here. I'll do some thinking and check with [~dl] as well.
12-03-2024
Christian is right. It's possible that code executed in the common pool does attempt to set the thread's CCL. So we will need to look at this again, maybe reset if changed by a task.
12-03-2024
The fix for this issue https://github.com/openjdk/jdk/pull/18144 has a compatibility impact that might have been overlooked: Using `InnocuousForkJoinWorkerThread` means that any task that runs in the common pool can no longer use `Thread.currentThreaad().setContextClassLoader(...)` - that unconditionally throws a `SecurityException`. Shouldn't a fix with such an impact at least require a CSR and proper documentation?
11-03-2024
[~shade] please see https://github.com/openjdk/guide/pull/119 The use of the "Affects Version" field is trying to be made more consistent/stable and have everyone follow the same rules. If you have feedback please provide in the above PR. > Once you removed 21 as affected versions here, this issue went off my 21u pending backports radar. Again please raise this in the above PR. It sounds like your filtering mechanisms are at odds with the proposed field usage.
10-03-2024
> Affects 19 implies affects 20, 21, 22, 23. - per the dev guide. Well, OpenJDK Dev Guide also allows specifying more versions: "Adding an additional value for a separate release family where it’s still reproducible, e.g. 12, isn’t necessary but ok, especially if there’s been a few releases since the latest version noted." This is what we have been doing for a while now, for a good reason. Having the explicit versions set simplifies the backport reports that could ask very directly "What bugs are affecting 21?" The version comparisons get weird otherwise, since the versions are not exactly numbers, and there is a clear distinction between "21" and "21.0.3", for example. Once you removed 21 as affected versions here, this issue went off my 21u pending backports radar. So I'd say: supply the minimal version on the issues if you want (OpenJDK Dev Guide suggests to use minimal version), but let's not go around and remove the versions from existing bugs set by others (OpenJDK Dev Guide allows explicit versions).
08-03-2024
Affects 19 implies affects 20, 21, 22, 23. - per the dev guide.
08-03-2024
All right, we would need to pick up the fix to 21u then. I opened the PR against jdk21u-dev to test it, while the change stabilizes in mainline.
07-03-2024
[~shade] Yes, I think that it starts with 19 so I added 19 and 20 to the list of affected versions. Thanks!
07-03-2024
This looks like a regression from JDK-8277090 in JDK 19, right?
07-03-2024
Changeset: 53c4714a Author: Viktor Klang <vklang@openjdk.org> Date: 2024-03-07 09:44:35 +0000 URL: https://git.openjdk.org/jdk/commit/53c4714aab2e072ba18631875dcaa3b2d5d22243
07-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18144 Date: 2024-03-06 22:58:54 +0000
06-03-2024