1
Provide a bulk OopHandle release mechanism with the ServiceThread
source link: https://bugs.openjdk.org/browse/JDK-8297168
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Provide a bulk OopHandle release mechanism with the ServiceThread
Details
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.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK