Use MEM_64K_PAGES on Windows

[MichalPetryka]

Description

It seems that Windows 10 VirtualAlloc2 provides a new flag, MEM_64K_PAGES that's a hint that lets it page memory more efficiently.

The only requirement it seems is that the allocation size and base must be 64kB aligned.

AFAIR dotnet already aligns the sizes to 64kB due to that being the allocation granularity on Windows so it seems to me that this could be used by GC and VM if the API is available?

cc @jkotas if you see any issue here

Configuration

Windows

Regression?

n/a

Data

https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc2

[dotnet-policy-service]

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

[ahmed605]

I think it's worth mentioning that VirtualAlloc2 is 17134+ (not Windows 10 baseline), but I think it should be possible to use MEM_64K_PAGES with NtAllocateVirtualMemory on 14393+

[jkotas]

AFAIR dotnet already aligns the sizes to 64kB due to that being the allocation granularity on Windows

Reservation sizes are aligned to 64kB. Commit sizes are aligned to page size that is 4kB on Windows. I think this option would require aligning commit sizes to 64kB. It would effectively mean changing the page size used by the VM and GC as OS memory allocation granularity to 64kB.

[jkotas]

I agree that using this option when it is available would be a perf improvement. It reduces TLB pressure.

[MichalPetryka]

It would effectively mean changing the page size used by the VM and GC as OS memory allocation granularity to 64kB.

It seems to me like that'd have minimal memory waste since it'd basically just pad the heap sizes to 64kB and it seems to me like it could potentially simplify things to use 64kB on all 64bit platforms anyways since the code needs to already handle AMR64 with 64KB pages.