RFR: 8220240: Refactor shared dirty card queue
kim.barrett at oracle.com
Sat Mar 9 00:20:33 UTC 2019
Please review this change which adds a new class, G1SharedDirtyCardQueue, in
order to allow some simplifications of the PtrQueue class and classes derived
An instance of this new class has been added to the G1BarrierSet, and is now
used by the one place that was formerly enqueuing to the shared dirty card
queue in the barrier set's dirty card qset.
As there are no longer any enqueues to the queue in a dirty card qset, that
queue has been removed. (JDK-8219613 already removed the similar queue from
SATB qsets). This also allows the elimination of the _lock and _permanent
members of PtrQueue and associated code.
Some places that were dealing with cards logged in the queue embedded in qsets
(specifically abandon_logs and concatenate_logs) now deal with the new shared
queue in the barrier set. This makes it even more obvious that these
operations are incorrectly placed. They aren't really generic operations on
dirty card qsets at all, and really belong to the barrier set and should be
applied only to its qset. I intend to move them in a following cleanup.
With the various changes to PtrQueue, PtrQueueSet, and their derivatives, here
and in previous changes, I think we're close to (but not quite there yet)
eliminating the need for two-phase construction of PtrQueueSets. I intend to
look at the elimination of the initialize() function as a followup cleanup.
G1SharedDirtyCardQueue is still lock-based, using Shared_DirtyCardQ_lock,
which still needs to have access-related rank. It could be made lock-free, if
the elimination of that access-related lock seems sufficiently important to
warrant the extra complexity. The situation where the shared queue is needed
is extremely rare, so contention for the lock isn't an issue. This can be
addressed in a followup improvement.
I'll update copyrights before pushing.
mach5 tier1-3, hs-tier4-5
More information about the hotspot-gc-dev