RFR: 8230404: Refactor logged card refinement support in G1DirtyCardQueueSet

Stefan Johansson stefan.johansson at oracle.com
Thu Sep 5 13:31:14 UTC 2019

Hi Kim,

On 2019-08-31 08:09, Kim Barrett wrote:
> 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/

The change looks good, indeed easier to follow the code now.

Had one thought around G1CardTableEntryClosure::apply_to_buffer, and if 
that should be in a separate closure that wraps the 
G1CardTableEntryClosure where needed. Not a big thing and if you prefer 
it to keep the code as is I don't mind.


> Testing:
> mach5 tier1-5

More information about the hotspot-gc-dev mailing list