Correct values for HighMemoryLoadThresholdBytes, MemoryLoadBytes.

[naricc]

Correct values fort HighMemoryLoadThresholdBytes, MemoryLoadBytes. I looked in the code for CoreCLR and spoke with Maoni Stephens and Jan Kotas about the values used in CoreCLR, so I am confident they are all correct now.

HighMemoryThresholdBytes is a system wide memory usage threshold at which CoreCLR changes its compaction strategy. There is no direct correspondance to anything in mono-sgen. But since it used by software caches to determine when memory in the system is "nearly" exhauste, mono-sgent will use .9 * total physical memory as an acceptable value.

[BrzVlad]

@naricc was there something left to fix for TotalAvailableMemoryBytes ? Since that was the name of the old PR

[naricc]

@naricc was there something left to fix for TotalAvailableMemoryBytes ? Since that was the name of the old PR

@BrzVlad
I had thought that needed fixing, but after looking at CoreCLR, it turns out it does not. It is supposed to be the total amount of physical memory in the machine, regardless if any part of it is already used. This is the value it already has in mono-sgen.

[CoffeeFlux]

Isn't all this copy-pasted? Please put the function in a header and have it only declared once.

[CoffeeFlux]

LGTM, though if this fixes the GCMemoryInfo corefx test please re-enable that before merging and mark this PR as fixing the corresponding issue.

[naricc]

@CoffeeFlux It seems there is still an issue with fragmentation regarding that test I will have to look into before I can re-enable it.

[mikernet]

Which platforms are affected by the issue this addresses and what is the nature of the issue exactly - is it completely broken, slightly off, etc..?

Are the values provided in .NET Core 3.1 running on Windows reliable for the purpose of cache management?

[CoffeeFlux]

@mikernet this is a Mono-specific change, so it does not affect .NET Core 3.1. We only just recently added the API to Mono as part of larger .NET 5 work, so it has yet to ship to anyone yet :)