RFR (M/L): 8247928: Refactor G1ConcurrentMarkThread for mark abort (JDK-8240556)
thomas.schatzl at oracle.com
Thu Jun 25 08:56:12 UTC 2020
can I have reviews for this change that refactors the
G1ConcurrentMarkThread class to prepare it better for mark abort
So the idea in the latter is to abort the concurrent cycle if after
concurrent start gc we find that old gen occupancy actually went down
below the IHOP again due to e.g. eager reclaim. To do that, G1 needs to
scrub any marks on the next bitmap during the gc pause.
The current, original change just performs this work in the pause, which
is very slow, so the idea is to do the bitmap cleaning concurrently
instead. The problem is that G1ConcurrentMarkThread is a mess and you
can't easily "jump" to the end of the current marking.
Additionally, the code was worth refactoring without that requirement
This change refactors the code so that it is much easier to do add a
second path through the concurrent cycle.
Overall, there are two options to do that:
1) provide an explicit state machine for the concurrent marking so that
you can jump to the end easily.
2) provide building blocks that can be easily put together to implement
the second path.
While 1) works (there is a sample POC at
http://cr.openjdk.java.net/~tschatzl/8247928/webrev.sm/), I found that
it is much more code and less understandable than just building two
paths through the marking cycle as in the "abort marking" case we only
need to do the very tail end of the regular full marking cycle, so I
propose this option for review.
This is refactoring (almost) only, the additional path should be added
with JDK-8240556. Almost because I changed two things:
- the concurrent mark (control) thread does not do any marking any more
for a long time (long long ago it did root scanning/marking), so I
removed the _vtime_mark_accum accumulator.
- the "Concurrent Mark" finish message is now only printed at the end of
all marking, not every iteration. First, the restart case is very rare
so probably anyone parsing it will not handle this case correctly, and
the contents (times) of that finish message are confusing, which means
most likely anyone handling it will likely do the wrong thing.
The "Concurrent Mark Restart for Mark Overflow" remains to indicate a
Based on JDK-8248221 also out for review.
tier1-5, a few local jtreg runs of the gc directory
More information about the hotspot-gc-dev