limit regions_range to 2x physical_mem for NativeAOT

[mangod9]

this will work better for scenarios where multiple NativeAOT libraries are used within a process.

This will alleviate GC initialization for certain scenarios, but manual configuration might be needed. Perhaps we can improve the error message when we fail to reserve the regions_range.

[Copilot]

Pull Request Overview

This PR modifies the garbage collector initialization in NativeAOT to use a more conservative memory reservation strategy. Instead of using the larger of 256GB or 2x physical memory, NativeAOT will now only reserve 2x physical memory for its regions range.

• Reduces memory reservation footprint for NativeAOT applications
• Better accommodates scenarios with multiple NativeAOT libraries in a single process
• Maintains existing behavior for non-NativeAOT runtimes

Comments suppressed due to low confidence (1)

[dotnet-policy-service]

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

[MichalStrehovsky]

The comment at #118433 (comment) makes it appear this might cause performance issues that we do not understand. I would prefer not having a native AOT specific configuration that causes perf issues we do not understand.

[jkotas]

I agree with Michal that it is not desirable to have diverging GC defaults between regular CoreCLR and NativeAOT, in particular if we believe that it causes performance issues.

Our test strategy for NativeAOT assumes that NativeAOT is identical to regular CoreCLR as much as possible. If we were to start diverging NativeAOT and CoreCLR behavior with GC defaults, we would need to introduce duplicated test and perf coverage for NativeAOT.

[mangod9]

We were considering whether we can make the change globally for WKS, but that needs more thought (so perhaps in 11). We can look into a better message when GC is unable to reserve space.

[mangod9]

@Maoni0, was chatting with @agocke today and wondering if extending the 2x physical_mem reservation for WKS is going to be a risky behavior change? Are you aware of cases where that would lead to functional and/or perf issues?

[Maoni0]

I think it's fine to make the change for WKS but you'd want to do some perf runs. note that on large machines this can of course mean more than 256GB reserved. and if you anticipate nativeaot apps to run on large systems (like a little service running along side large server apps), you'd probably want to put a cap on that so you'd want min (2x physical mem, some cap) (ie, the reverse of what we are doing now).