Approximate the heap_hard_limit

[cshung]

It appears to me that the field gc_heap::heap_hard_limit is also used as a heuristic to determine generation to condemn. If we set it to 1, the heuristic would think we are going to run out of memory and keep triggering gen 2 GC.

This change approximates the heap_hard_limit value by adding the individual object heaps. This is an approximation because we discounted the memory that would be used for the auxiliary structures (such as the card table)

@dotnet/gc

[ghost]

Tagging subscribers to this area: @Maoni0
Notify danmosemsft if you want to be subscribed.

[Maoni0]

[mjsabby]

Is this a regression? What is the impact of this change for someone using Large Pages + hard limit?

[cshung]

Is this a regression? What is the impact of this change for someone using Large Pages + hard limit?

@mjsabby - In short - yes, it is - and this change will make large Pages + hard limit better.

The story started with your discovery that the 3x commit introduced by POH is a blocker for you.

The root cause of the 3x commit is because when given a single hard limit, we do not know if the application is going to use that for which object heap, and therefore we assumed the worst.

For the normal scenario without large pages, that is okay because we just reserved the memory without committing it.

With large pages, implementation forces us to commit upfront, and therefore we committed 3x the hard limit, and that is not okay

Therefore I introduced a new way to specify the hard limit per object heap, that eliminated the guesswork the runtime is doing:

• Tracking how much memory is committed per object heap #36731
• Allow user to specify independent heap hard limits for different object heaps. #37166

By specifying the hard limit for individual object heaps, the runtime will commit exactly as specified.

As an example, I wish to have 1G in SOH, 2G in LOH, and 500M in POH, you would specify

COMPLUS_GCHeapHardLimitSOH=1G (in hex)
COMPLUS_GCHeapHardLimitLOH=2G (in hex)
COMPLUS_GCHeapHardLimitPOH=500M (in hex)

The runtime will reserve (or commit in large page case) 3.5G upfront and distribute them as instructed.

Just to be clear, if the application happens to allocate more than 1G in SOH, then it will OOM, regardless of whether or not we still have memory in LOH or POH.

After that, I worked on testing it. After #37725, the code works functionally, but it has a performance bug. When individual heap hard limits are provided, the heuristic to determine which generation to condemn is broken. In particular, it chose to perform a gen 2 background GC always.

This is caused by my ignorance. I thought the field heap_hard_limit is used only for checking whether or not we exceed the limit, turn out it is also used to determine available memory, and thus impact the choices the heuristic would make.

By setting heap_hard_limit to approximately what it should be, this change fixed the heuristic, and it will choose the same generation to condemn as it sees fit.

So for a longer summary:

• The 3x commit issue is solved
• My implementation had a couple of bugs, but they are fixed by now.