New GC decommit strategy for large/huge regions

[markples]

• Use age rather than budget for determining whether large and huge regions should be decommitted
  • Combine new age logic with previous age logic for basic regions
  • Simply add aged regions to decommit list. In the future, this can be combined with move_highest_free_regions with age swapping to optimize which regions are decommitted
  • Factor modified portions of distribute_free_regions into helper functions
  • Simplify distribute_free_regions when logic now only applies to basic regions
• Add logic to more aggressively decommit in high-memory-usage situations
• Call distribute_free_regions during BGC (or during ephemeral "pre-GC" to a BGC if one occurs)

[dotnet-policy-service]

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

[Maoni0]

since this can be set by a config it can be smaller than 5 so this can't be an unsigned number.

[markples]

good catch, thanks - note also that ~25 lines up there was a possibility for overflow

[Maoni0]

Mark and I talked about the following couple of changes that he'll do but in general this looks good and we've gone through the perf results -

1. make sure we are doing the right check for when we want to decommit (in distribute_surplus_p) called at the beginning of a BGC mark phase
2. add a comment that talks about the policies and operations on the global and local lists (I've written an example for him)
3. the calc of almost_high_memory_load_th in the comment above
4. a couple of nit changes for naming

[markples]

Done but (2)

1. make sure we are doing the right check for when we want to decommit (in distribute_surplus_p) called at the beginning of a BGC mark phase

I believe this is correct. Previously we never called distribute_free_regions at this point, but we could call it during an ephemeral gc that is triggered at the start of BGC. In that case, we would choose to decommit a positive balance (background_running_p() is false). We want BGC behavior to match this possible ephemeral GC (as the ephemeral GC is optional (a policy choice) but we don't want distribute_free_regions behaving differently based on this decision). We have distribute_surplus_p return true if (settings.condemned_generation != max_generation), which means it returns false if condemned generation is 2 (BGC, not a foreground GC during BGC). Returning false means we don't distribute but instead decommit, which is what we want.

This will go in the comments.

2. add a comment that talks about the policies and operations on the global and local lists (I've written an example for him)
3. the calc of almost_high_memory_load_th in the comment above

fixed this and a nearby similar problem

4. a couple of nit changes for naming

done

[markples]

Comment added for (2)

[markples]

I manually built a new commit with all of these changes as rebase operations to squash some commits together were retriggering old merge conflicts. To see the most recent changes separately, see my backup branch https://github.com/markples/runtime/tree/new-dfr-backup or the specific commits:

fix underflow possibility and nearby overflow one
decide_on_decommit_strategy
dst -> dest to match majority of file
Rename remove_surplus_regions->trim_region_list and add_regions->grow_region_list.
dfr comment

or those 5 squashed in https://github.com/markples/runtime/tree/new-dfr-backup-squash at 3eef23b

[markples]

all region

that we can

[markples]

this matches old policy. if not decommit then we distribute evenly. "foreground GC" is enough (means during BGC)