RFR (M/L): 8247928: Refactor G1ConcurrentMarkThread for mark abort (JDK-8240556)

[Thomas Schatzl]

Hi all,

   can I have reviews for this change that refactors the 
G1ConcurrentMarkThread class to prepare it better for mark abort 
(JDK-8240556).

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 
anyway ;)

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 
restart.

Based on JDK-8248221 also out for review.

CR:
https://bugs.openjdk.java.net/browse/JDK-8247928
Webrev:
http://cr.openjdk.java.net/~tschatzl/8247928/webrev/
Testing:
tier1-5, a few local jtreg runs of the gc directory

Thanks,
   Thomas