RFR: 8258431: Provide a JFR event with live set size estimate

[Thomas Schatzl]

On Mon, 15 Feb 2021 17:23:44 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> The purpose of this change is to  expose a 'cheap' estimate of the current live set size (the meaning of 'current' is dependent on each particular GC implementation but in worst case 'at last full GC') in form of a periodically emitted JFR event.
> 
> ## Introducing new JFR event
> 
> While there is already 'GC Heap Summary' JFR event it does not fit the requirements as it is closely tied to GC cycle so eg. for ZGC or Shenandoah it may not happen for quite a long time, increasing the risk of not having the heap summary events being present in the JFR recording at all. 
> Because of this I am proposing to add a new 'Heap Usage Summary' event which will be emitted periodically, by default on each JFR chunk, and will contain the information abut the heap capacity, the used and live bytes. This information is available from all GC implementations and can be provided at literally any time.
> 
> ## Implementation
> 
> The implementation differs from GC to GC because each GC algorithm/implementation provides a slightly different way to track the liveness. The common part is `size_t live() const` method added to `CollectedHeap` superclass and the use of a cached 'liveness' value computed after the last GC cycle. If `liveness` hasn't been calculated yet the implementation will default to returning 'used' value.
> 
> The implementations are based on my (rather shallow) knowledge of inner working of the respective GC engines and I am open to suggestions to make them better/correct.
> 
> ### Epsilon GC
> 
> Trivial implementation - just return `used()` instead.
> 
> ### Serial GC
> 
> Here we utilize the fact that mark-copy phase is naturally compacting so the number of bytes after copy is 'live' and that the mark-sweep implementation keeps an internal info about objects being 'dead' but excluded from the compaction effort and we can these numbers to derive the old-gen live set size (used bytes minus the cumulative size of the 'un-dead' objects).
> 
> ### Parallel GC
> 
> For Parallel GC the liveness is calculated as the sum of used bytes in all regions after the last GC cycle. This seems to be a safe bet because this collector is always compacting (AFAIK).
> 
> ### G1 GC
> 
> Using `G1ConcurrentMark::remark()` method the live set size is computed as a sum of `_live_words` from the associated `G1RegionMarkStats` objects. Here I am not 100% sure this approach covers all eventualities and it would be great to have someone skilled in G1 implementation to chime in so I can fix it. However, the numbers I am getting for G1 are comparable to other GCs for the same application.
> 
> ### Shenandoah
> 
> In Shenandoah, the regions are keeping the liveness info. However, the VM op that is used for iterating regions is a safe-pointing one so it would be great to run it in an already safe-pointed context.
> This leads to hooking into `ShenandoahConcurrentMark::finish_mark()` and `ShenandoahSTWMark::mark()` where at the end of the marking process the liveness info is summarized and set to `ShenandoahHeap::_live` volatile field - which is later read by the event emitting code.
> 
> ### ZGC
> 
> `ZStatHeap` is already holding the liveness info - so this implementation is just making it accessible via `ZCollectedHeap::live()` method.

The change also misses liveness update after G1 Full GC: it should at least reset the internal liveness counter to 0 so that `used()` is used.
I think there is the same issue for Parallel Full GC. Serial seems to be handled.

src/hotspot/share/gc/shared/collectedHeap.hpp line 217:

> 215:   virtual size_t capacity() const = 0;
> 216:   virtual size_t used() const = 0;
> 217:   // a best-effort estimate of the live set size

I would prefer @shipilev's comment. Also I would like to suggest to call this method `live_estimate()` to set the expectations right.

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1114:

> 1112: 
> 1113:   _g1h->set_live(live_size * HeapWordSize);
> 1114: 

This code is located in the wrong place. It will return only the live words for the areas that have been marked, not eden or objects allocated in old gen after the marking started.

Further it iterates over all regions, which can be large compared to actually active regions.

A better place is in `G1UpdateRemSetTrackingBeforeRebuild::do_heap_region()` after the last method call - at that point, `HeapRegion::live_bytes()` contains the per-region number of live data for all regions.

`G1UpdateRemSetTrackingBeforeRebuild` is instantiated and then called by multiple threads. It's probably best that that `HeapClosure` locally sums up the live byte estimates and then in the caller `G1UpdateRemSetTrackingBeforeRebuildTask::work()` sums up the per thread results like is done for `G1UpdateRemSetTrackingBeforeRebuildTask::_total_selected_for_rebuild`, which is then set in the caller of the `G1UpdateRemSetTrackingBeforeRebuildTask`.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1850:

> 1848: size_t G1CollectedHeap::live() const {
> 1849:   size_t size = Atomic::load(&_live_size);
> 1850:   return size > 0 ? size : used();

note that `used()` is susceptible to fluttering due to memory ordering problems: since its result consists of multiple reads, you can get readings from very different situations.
It is recommended to use `used_unlocked()` instead, which does not take allocation regions and archive regions into account, but at least it is not susceptible to jumping around when re-reading it in quick succession.

src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp line 49:

> 47:   _young_live = young_gen()->used_in_bytes();
> 48:   _eden_live = young_gen()->eden_space()->used_in_bytes();
> 49:   _old_live = old_gen()->used_in_bytes();

`_young_live` already seems to contain `_eden_live` looking at the implementation of `PSYoungGen::used_in_bytes()`:

I.e.

`size_t PSYoungGen::used_in_bytes() const {
  return eden_space()->used_in_bytes()
       + from_space()->used_in_bytes();      // to_space() is only used during scavenge
}
`

but maybe I'm wrong here.

src/hotspot/share/gc/shared/genCollectedHeap.cpp line 683:

> 681:   }
> 682:   // update the live size after last GC
> 683:   _live_size = _young_gen->live() + _old_gen->live();

I would prefer if that code were placed into `gc_epilogue`.

src/hotspot/share/gc/shared/space.inline.hpp line 189:

> 187:         oop obj = oop(cur_obj);
> 188:         size_t obj_size = obj->size();
> 189:         live_offset += obj_size;

It seems more natural to me to put this counting into the `DeadSpacer` as this is what this change does. Also, the actual dead space "used" can be calculated from the difference between the `_allowed_deadspace_words` and the maximum (calculated in the constructor of `DeadSpacer`) afaict at the end of evacuation. So there is no need to incur per-object costs during evacuation at all.

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

Changes requested by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2579