RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings

[Thomas Schatzl]

Hi all,

  can I get reviews for this change that removes an assert with a wrong
condition?

The problem is that G1 remset management intentionally does not
properly synchronize state when one thread adds a remembered set entry
to a fine PRT and another thread coarsens that one. In that case, the
PRT's bitmap and separate occupancy counter can get inconsistent in
basically all possible benign ways (i.e. one bit too many in the
bitmap, or one bit too few) every time.

This behavior is documented at the top of heapRegionRemSet.cpp, but the
assert tries to verify that the number of iterated fine PRT remembered
set entries corresponds to what the fine PRT thinks it is.

My solution to that problem is to remove that assert (and some
additional dead code that does the same thing). The reason is that
fixing this assert seems not worth the effort:

- the existing assert is only checked if we have only one worker
thread. This seems unusual nowadays, kind of supported by the fact that
this assert has been introduced on day one, and apparently never before
triggered in this case.

- one could add a check to further tighten the assert, i.e. only check
if there were no coarsenings; however the #coarsenings counter is a
global right now, which means that any remembered set coarsening at any
point during execution disables this check completely.

- one could do extensive analysis of the situation and then update the
PRTs to fix it so that next time we don't need to get into this
situation again. However, that would make the assert even slower
(counting occupied cards is very slow), and I am kind of against an
assertion that updates state...

CR:
https://bugs.openjdk.java.net/browse/JDK-8173229
Webrev:
http://cr.openjdk.java.net/~tschatzl/8173229/webrev/
Testing:
Did 1000+ runs of that test with remembered set verification without
issues. Previous runs showed that the situation occurs every 50-100
runs, so it should have been checked a few times already.

Thanks,
  Thomas