RFR: 8317371: GenShen: Needs improved support for humongous allocation [v3]

[Kelvin Nilsen]

On Fri, 13 Oct 2023 00:37:06 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 566:
>> 
>>> 564:     size_t first_old_region, last_old_region;
>>> 565:     double density;
>>> 566:     fragmentation_trigger_reason(density, first_old_region, last_old_region);
>> 
>> Just use the member fields here?
>
> I'm not sure which member fields you are recommending here.
> 
> ShenandoahFreeSet remembers first and last indexes of the OldCollector free set, but the range we are interested in here includes all retired old-gen regions in addition to the free regions.
> 
> If I'm misunderstanding your suggestion, please clarify.

Not sure which member fields.  Please clarify.

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 572:
>> 
>>> 570: 
>>> 571:     // New active regions may have came into play following the trigger.
>>> 572:     size_t first_region = MIN2(first_active_region, first_old_region);
>> 
>> I don't understand this. The active region counts are not updated after the trigger?
>
> I agree this is confusing.  I'm going to simplify this code and have the log message report the data that drove the trigger.  The reality is that between the moment in time that we raised the trigger (from inside ShenandoahHeap::rebuild_free_set(), and the moment that the regulator polls the old heuristic's state to discover that we should_start_gc(), the state may change so this log message may be slightly out of date.  This would be extremely unlikely.  The trigger happens at final-update-refs.  The old-gen state will not change until we begin a subsequent evacuation phase.

Will simplify this code to make it more clear.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/336#discussion_r1357605401
PR Review Comment: https://git.openjdk.org/shenandoah/pull/336#discussion_r1357604738