RFR: Full region promotion

[Kelvin Nilsen]

On Mon, 4 Oct 2021 16:16:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this patch, full-region-promotion occurred during the final-evacuation safepoint.  When heap regions are very large (e.g. 16 MB) and a large number of heap regions need to be promoted, this was measured to require over 500 ms in certain scenarios.  Another disadvantage of the prior implementation is that entire heap regions are promoted as-is without any compaction.  A problem with this is that all fragments of garbage within the young-region are promoted into old-gen, where the target heap-region utilization is generally much higher than heap-utilization target within young-gen memory.  Once promoted, it is much more costly to compact this memory because an old-gen collection is much more expensive than a young-gen collection.
>> 
>> This patch moves region promotion out of the safepoint.  Regions that have reached the tenure age are biased for inclusion within the collection set and are processed during concurrent evacuation using the established conventions.  Humongous heap regions are also promoted during concurrent evacuation rather than during the safepoint.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 890:
> 
>> 888: 
>> 889:   // Since this region may have served previously as OLD, it may hold obsolete object range info.
>> 890:   heap->card_scan()->reset_object_range(bottom(), bottom() + spanned_regions * ShenandoahHeapRegion::region_size_words());
> 
> Do we write this memory again on line 911 or 915?

The code at lines 911 and 915 clears or sets the card dirty bits.  The code here at line 890 changes the remembered set's knowledge of where objects begin.  These are two different activities.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 804:
> 
>> 802:   size_t num_clusters = (size_t) ((num_heapwords - 1 + cluster_size) / cluster_size);
>> 803: 
>> 804:   if (!region->is_humongous_continuation()) {
> 
> Is this safe? why do we no longer need to scan humongous continuations?

humongous continuations are scanned when the humongous start that "governs" the continuation is scanned.  I'll add a comment here.

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

PR: https://git.openjdk.java.net/shenandoah/pull/75