JDK-8369238 : Allow virtual thread preemption on some common class initialization paths
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25,26
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-10-06
  • Updated: 2025-11-11
  • Resolved: 2025-11-04
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 26
26 b23Fixed
Related Reports
Blocks :  
Relates :  
Sub Tasks
JDK-8371412 :  
Description
If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.

As of JDK-8338383, virtual threads blocked in the VM on ObjectMonitor operations can be preempted. Since synchronization on class initialization is implemented using ObjectLocker, we can reuse the same mechanism to preempt all virtual threads blocked waiting for a class to be initialized along some of the most common initialization paths, in particular, when executing invokestatic, new, getstatic and putstatic from the interpreter.
Comments
Ouch. So if this persists as real-world problem, we might (grudgingly) consider backporting it to 25u. The changeset is fairly big, but I think that is because it touches interpreter and rewires a few asserts, so the actual product code exposure might be not that great.
06-11-2025

Changeset: c6a88155 Branch: master Author: Patricio Chilano Mateo <pchilanomate@openjdk.org> Date: 2025-11-04 23:32:41 +0000 URL: https://git.openjdk.org/jdk/commit/c6a88155b519a5d0b22f6009e75a0e6388601756
04-11-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27802 Date: 2025-10-14 13:42:18 +0000
14-10-2025