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.
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.
Attachments
Issue Links
- relates to
-
JDK-8296463 Memory leak in JVM_StartThread with the integration of Virtual threads
-
- Resolved
-
-
JDK-8244997 Convert the JavaThread::_threadObj oop to use OopStorage
-
- Resolved
-
