RFR: 8325857: G1 Full GC flushes mark stats cache too early

[Thomas Schatzl]

Hi all,

  please review this fix that flushes mark stats cache after reference processing because that phase can mark some objects. Apart from a minor performance issue (the amount live data is used to determine whether a region is considered for the dead-wood optimization only, so at most g1 full gc compacted too much) there has been no correctness issue.

In this patch the work is performed serially because even on not-so-current processors this phase takes < 1ms for up to 256 threads (~0.004ms per parallel gc thread).

There is a prototype for a parallel version at https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/8325857-wrong-mark-cache-flush?expand=1 (ugly code) that costs, depending on the machine <= 0,1ms (slightly older machine, 36 threads) or <= 0.03ms (current machine, 256 threads), but introducing like 30 LOC + some magic constant.

I assume that one does not use/force such large #threads to run tiny applications where the other part of g1 full gc only takes time where even that 1ms matter, so saving a bit on code complexity. If somebody disagrees with that analysis, I can change the code to use the parallel version.
Additionally g1 full gc is kind of an error condition anyway.

Testing: gha

Hth,
  Thomas

-------------

Commit messages:
 - 8325857: G1 Full GC flushes mark stats cache too early

Changes: https://git.openjdk.org/jdk/pull/17979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325857
  Stats: 8 lines in 2 files changed: 7 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17979/head:pull/17979

PR: https://git.openjdk.org/jdk/pull/17979