RFR: 8230404: Refactor logged card refinement support in G1DirtyCardQueueSet

Kim Barrett kim.barrett at oracle.com
Sat Aug 31 06:09:18 UTC 2019


Please review this refactoring of logged card refinement.

We presently have two cases embedded in G1DirtyCardQueueSet. There is
support for both concurrent refinement and during GC (STW) refinement.
These cases share some code, but that code sharing causes more
problems than it solves.

The yield to safepoint request handling in the concurrent case is
embedded in the closure and reported via the bool return value, making
for some awkwardness and ambiguity in the shared helper code as to
whether the current card was processed or not.

STW refinement needs to go through the DCQS lock and deal with the
head/tail/count in the DCQS list representation. It performs a useless
stop_at check.  And it needs to have a closure that returns bool but
must always return true.

By separating these two cases we end up removing more code than we
add, and substantially simplify both.  This also fixes a bug in
counting buffers processed concurrently: _processed_buffers_rs_thread
was being incremented for both concurrent refinement and STW
refinement, but being reported as being for concurrent refinement.
(The only use of that information currently is in logging.)  This
might get a small performance benefit from STW refinement dealing with
a lock-free stack rather than dealing with the DCQS lock, but I didn't
try to measure that.

CR:
https://bugs.openjdk.java.net/browse/JDK-8230404

Webrev:
http://cr.openjdk.java.net/~kbarrett/8230404/open.00/

Testing:
mach5 tier1-5




More information about the hotspot-gc-dev mailing list