JDK-8297168 : Provide a bulk OopHandle release mechanism with the ServiceThread
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P3
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2022-11-17
  • Updated: 2022-11-21
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 20
20Unresolved
Related Reports
Relates :  
JDK-8244997 - Convert the JavaThread::_threadObj oop to use OopStorage
Relates :  
JDK-8296463 - Memory leak in JVM_StartThread with the integration of Virtual threads
Description
When a JavaThread terminates it has to release all OopHandles that it uses. This can't be done by the thread itself due to timing issues, so it is handed-off to the ServiceThread to do it - ref JDK-8244997.

Initially there was only one OopHandle to handle - that of the threadObj, but since Loom there are another 3 OopHandles to process. The existing logic does the hand-off one OopHandle at a time but that is a potential synchronization bottleneck because each hand-off acquires the ServiceLock, enqueues the OopHandle, issues a notify to (potentially) wakeup the ServiceThread and then release the ServiceLock. This can lead to high contention on the ServiceLock and also bad scheduling interactions with the ServiceThread.

We should provide one call that can process all of the OopHandles together.
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11254 Date: 2022-11-21 01:56:34 +0000
21-11-2022