RFR: Borrow from old gen

[Kelvin Nilsen]

On Mon, 7 Feb 2022 22:08:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 341:
> 
>> 339:   size_t penultimate_live_memory = get_penultimate_live_memory();
>> 340:   double original_cycle_time = avg_cycle_time;
>> 341:   if ((penultimate_live_memory < last_live_memory) && (penultimate_live_memory != 0)) {
> 
> The heuristic uses an exponentially weighted average for cycle times. The decay factor can be adjusted from the command line. The margin of error for estimating cycle times is also adjusted in response to degenerated cycles or successful concurrent cycles. Perhaps we should have the heuristic also adjust the decay factor? Have we evaluated the results of these changes on a variety of work loads?

Exposure to variety of workload conditions is very limited.  All of our work on heuristics needs much more attention.  Maybe we don't want to fiddle with these "quick and dirty" fixes until after we can do more thorough experimentation with different workloads.

One important observation I've made is that being too aggressive with heuristics is more harmful with generational mode than traditional mode.  With traditional mode, being too aggressive means we spend a few more cycles in GC.  With generational mode, it might mean we "starve" old-gen GC, and that might result in degenerated or Full STW pauses.

I'm ok to pull out these heuristic tweaks.  I expect this will all be re-done eventually.  I'm not sure how to deliver the best out-of-box experience to early evaluators.

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

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