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.
Thanks,
Stefan
>
> Testing:
> mach5 tier1-5
>
More information about the hotspot-gc-dev
mailing list