Currently we iterate over the CSet twice in serial mode, once before the GC and once after, to ensure that the RSets of the CSet regions are ready for parallel iteration (some of their fields have to be in a certain state for the correctness of the parallel claiming algorithm).

However, both iterations are pointless given that when a region is added to the CSet it will be collected and then freed (at least in the common case) so its CSet can be reset when the region is freed and be ready when the region is re-allocated and eventually added to the CSet.

One special case is that, when evacuation failure happens, some CSet regions might not be freed but be retained in the heap. In this case, we can reset the appropriate flags on their RSets during evacuation failure handling.

I'll piggyback on this CR the removal of the G1_REM_SET_LOGGING code. Even though it is disabled by default, we have not used for a while and it is of questionable benefit (and also contains two more CSet iterations!).