Add a time-based decay to the linear allocation model.

[PeterSolMS]

Real world scenario that motivated this allocated a huge amount of data once a day, leading to high gen 0 and gen 1 budgets (several GB).

After this, there was relatively little activity, cause gen 1 budget to take several hours to normalize.

The new logic discounts the previous desired allocation over a period of 5 minutes.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Real world scenario that motivated this allocated a huge amount of data once a day, leading to high gen 0 and gen 1 budgets (several GB).

After this, there was relatively little activity, cause gen 1 budget to take several hours to normalize.

The new logic discounts the previous desired allocation over a period of 5 minutes.

Author:	PeterSolMS
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[PeterSolMS]

This addresses issue #52592.

[mangod9]

Nit: remove one empty line?

[PeterSolMS]

Looking at the code, I think I should remove both of the empty lines - no reason to separate the declarations here, I think.

[mangod9]

will we build a test scenario in GCPerfSim to validate that the decay has the desired effect?

[PeterSolMS]

I will try, but it may be a bit involved.

[Maoni0]

this seems to be along the same lines of what we are doing for WKS GC in generation_to_condemn where we check against dd_time_clock_interval so I'm wondering if we should take advantage of that, ie, use dd_time_clock_interval (but we should specify different values for Server GC - I would suggest much bigger values there) as decay_time so it's generation aware.

also the way the change is now is modifying the existing behavior, it seems like it would be better to not modify the existing behavior when a GC happens soon enough, and start decaying when the elapsed time between this and last GC (of that generation) is longer than decay_time (and the longer it has been the less effect it should have). what do you think?

[PeterSolMS]

I thought about making the decay_time generation aware along the lines you suggested, but didn't see a good reason to do it. Gen 1 is the only generation where we collect routinely without having exhausted the budget.

Regarding your remark about modifying existing behavior, I did this on purpose so a case where gen 1 GCs happen often enough, but very early (i.e. only exhausting a tiny fraction of the gen 1 budget), wouldn't lead to us taking a long time to ramp down the gen 1 budget. As it happens, a decay time of 5 minutes is short enough to fix the test case (which does about 6 gen 1 GCs in the first hour after loading the big chunk of data), but it seems unwise to rely on this - with more load, of course the interval between gen 1 GCs may drop below the decay_time.

[Maoni0]

I thought about making the decay_time generation aware along the lines you suggested, but didn't see a good reason to do it. Gen 1 is the only generation where we collect routinely without having exhausted the budget.

in high memory load situation we could also collect gen2 often without having exhausted the budget but you could argue that the next gen2 will also happen without having exhausted budget due to the same reason and also gen2's surv rate is usually very high anyway.

Regarding your remark about modifying existing behavior, I did this on purpose so a case where gen 1 GCs happen often enough, but very early (i.e. only exhausting a tiny fraction of the gen 1 budget), wouldn't lead to us taking a long time to ramp down the gen 1 budget. As it happens, a decay time of 5 minutes is short enough to fix the test case (which does about 6 gen 1 GCs in the first hour after loading the big chunk of data), but it seems unwise to rely on this - with more load, of course the interval between gen 1 GCs may drop below the decay_time.

it's always a worry that when you change the existing perf behavior you will regress someone, thus the concern.

also the idea of the fraction is we take some percentage from the current budget and some from the previous budget, but now with decay_factor we are simply discounting some of budget. shouldn't this be

float prev_allocation_factor = (1.0 - allocation_fraction) * decay_factor;

new_allocation = (size_t)((1.0 - prev_allocation_factor) * new_allocation + 
                          prev_allocation_factor * previous_desired_allocation);

if we want to make the previous budget count for less based on the time factor?

[PeterSolMS]

also the idea of the fraction is we take some percentage from the current budget and some from the previous budget, but now with decay_factor we are simply discounting some of budget. shouldn't this be

float prev_allocation_factor = (1.0 - allocation_fraction) * decay_factor;

new_allocation = (size_t)((1.0 - prev_allocation_factor) * new_allocation +
prev_allocation_factor * previous_desired_allocation);

I think you are absolutely right. Will change the code accordingly.

[Maoni0]

LGTM!