JDK-8221360 : Eliminate Shared_DirtyCardQ_lock
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-23
  • Updated: 2022-02-10
  • Resolved: 2021-08-24
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 18
18 b12Fixed
Related Reports
Blocks :  
JDK-8272480 - Remove Mutex::access rank
Relates :  
JDK-8220240 - Refactor shared dirty card queue
Relates :  
JDK-8214997 - Crash holding 'access' lock can deadlock in JVMCI compiler thread
Relates :  
JDK-8139652 - Mutator refinement processing should take the oldest dirty card buffer
Relates :  
JDK-8279957 - Main refinement thread tries to wake up itself when re-enqueuing causing assertion failure
Description
G1SharedDirtyCardQueue is lock-based, using Shared_DirtyCardQ_lock, which needs to have access-related rank. It could be made lock-free.

Making it lock-free involves some additional complexity. There is a tradeoff between that complexity vs having an access-related rank lock. The situation where the shared queue is needed is extremely rare, so contention for the lock isn't an issue.
Comments
Changeset: 0597cde8 Author: Kim Barrett <kbarrett@openjdk.org> Date: 2021-08-24 13:17:37 +0000 URL: https://git.openjdk.java.net/jdk/commit/0597cde87deb5ba7bcd84e47b3c10329f758067d
24-08-2021
On further consideration, getting rid of the shared queue and using the thread-local queue to handle the case where the shared queue is currently used might be problematic. It seems like doing so either constrains things elsewhere or can lead to recursive refinement calls that might run into trouble or at least be tricky to think about.
07-02-2020
If mutator conscripted refinement were to enqueue the local buffer and then take a buffer from the queue set for processing, rather than processing the local buffer (as per JDK-8139652), then we wouldn't need the shared dirty card queue at all. We only need the shared queue, rather than using the current thread's local queue, because the current thread might be a conscripted mutator thread processing its own buffer.
29-08-2019