RFR [L][4/7]: 8180415: Rebuild remembered sets during the concurrent cycle

[Thomas Schatzl]

Hi all,

  just a note: alternatives to this 2-pass scheme were considered and
implemented, however overall performed worse. Also alternatives to
"only" fixing the long Cleanup/Scrubbing times were considered but
rejected due to similar reasons (e.g. JDK-7187490, which contains a lot
of comments about this).

One issue is that the remembered set add operation itself just does not
scale too well (which needs significant love anyway for other reasons
too, but that is a completely different issue), and in conjunction with
the already ongoing (already bandwidth intensive) marking the overall
result is a longer total cycle time.

There is already the already mentioned issue that during marking you do
not have too good information about the heap too, so you may end up
kind of blindly rebuilding remembered sets for the wrong regions.

A separate pass may in the future also allow gathering more data to
improve the selection of the rebuild region set (see e.g. JDK-8198419).

Of course, alternative suggestions and ideas welcome :)

Thanks,
  Thomas

On Mon, 2018-03-05 at 16:07 +0100, Thomas Schatzl wrote:
> Hi all,
> 
>   can I have reviews for this change that implements the bulk of the
> "rebuild remembered sets concurrently" mechanism?
> 
> This change modifies the management of remembered sets so that those
> are only maintained when they are useful. This roughly means:
> - always maintain remembered sets for young gen regions
> - (almost) always maintain remembered sets for humongous regions (for
> eager reclaim) as long as they meet the eager reclaim criteria.
> - never create remembered sets for archive regions
> - do not create remembered sets for any regions during full gc
> - do not create remembered sets for regions with evacuation failure
> 
> (The latter two decisions may not be optimal, but the idea was to
> strictly only maintain remembered sets for regions we are going to
> try
> to evacuate soon)
> 
> - create remembered sets for old gen regions after finishing marking
> (starting at the Remark pause), iff
> 
>   - the liveness of these regions indicate so (liveness <=
> G1MixedGCLiveThresholdPercent)
>   - any (non-objArray) humongous region that does not have a
> remembered
> set yet (eg. because of full gc)
> 
> (Please see the new G1RemSetTrackingPolicy implementation for exact
> details)
> 
> During the following "Rebuild Remembered Set" phase, that replaces
> the
> "Create Live Data" phase, all non-young regions that may contain
> outgoing pointers (i.e. excluding closed archive regions), G1 scans
> the
> live objects in the regions between bottom and TARS
> ("top_at_rebuild_start" - yes, that's new :) for inter-region
> references and add them to the appropriate remembered set.
> 
> The TARS, as the name indicates, is the top-value at the start of
> remark, and the regions contain live data between this value and
> bottom
> that needs to be scanned during this rebuild phase.
> 
> The reason for a new indicator is that nTAMS is *not* sufficient:
> during marking there might have been more allocations in the old gen
> that also need to be scanned for new references.
> 
> All references above TARS (and below the region's top) will be
> handled
> by the existing barrier mechanism.
> 
> After rebuild, during the Cleanup pause, we create the new
> (candidate)
> collection set, eventually filtering out more regions, like humongous
> ones that exceed the eager reclaim criteria.
> 
> The current state of the remembered set for a given region is tracked
> within the remembered set for that region (HeapRegionRememberedSet
> class): a remembered set can be either Untracked, Updating or
> Complete.
> Untracked means that we do not manage a remembered set for this
> region,
> Complete means just that, and Updating means that we are currently in
> the process of updating the remembered set. This distinction is
> relevant for evacuation, e.g. we obviously must not evacuate not-
> Complete remembered sets.
> 
> Note that this change contains one single temporary ugly hack that
> allows G1 to work until the next change :) - so in this change G1
> determines whether there will be a mixed gc phase during the Cleanup
> pause. It needs to determine this information at that time, instead
> of
> previously during concurrent cleanup, to, if there is no mixed gc
> coming, drop all remembered sets to not maintain them further.
> 
> For this reason, and to avoid duplicate recalculation that may yield
> different results after dropping remembered sets, there is a new flag
> mixed_gc_pending in CollectorState, making it even more complicated.
> That one is going away in the next change, promised. :)
> 
> Some imho useful messages about remembered set tracking are printed
> using "gc, remset, tracking" log tags, both in debug and trace level.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8180415
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8180415/webrev/index.html
> Testing:
> hs-tier 1-5, etc. etc.
> 
> Thanks,
>   Thomas