RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings
erik.helin at oracle.com
Thu Jan 26 13:13:01 UTC 2017
On 01/26/2017 12:25 PM, Thomas Schatzl wrote:
> Hi all,
> can I get reviews for this change that removes an assert with a wrong
> 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...
Looks good, Reviewed. Thanks for fixing this!
> 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.
More information about the hotspot-gc-dev