GCMemoryInfo.MemoryLoadBytes does not reflect whats inside MEMORYSTATUS

[msedi]

Description

Irecently came across an issue where I wanted to get rid of the windows API method GetGlobalMemoryEx method and switch to the GC.GetMemoryInfo() to make my applications more platfom-independent.

From the description of the GCMemoryInfo it says for GCMemoryInfo.MemoryLoadBytes.

On Windows, memory load is a field in the MEMORYSTATUS structure. It's a number between 0 and 100 that specifies the approximate percentage of physical memory that's in use (0 indicates no memory use and 100 indicates full memory use). Corresponding information is given on other operating systems.

When looking at MEMORYSTATUS in https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus this seems to be correct. When I call the GC.GetMemoryInfo() though, the value in GCMemoryInfo.MemoryLoadBytes is not between 0 and 100.

Looking deeper in it, it seems more that the value contains MEMORYSTATUS.dwAvailPhys.

Is this a known behavior?

Reproduction Steps

Simply call GC.GetMemoryInfo() and compare to the corresponding windows GetGlobalMemoryStatus API call.

Expected behavior

GCMemoryInfo.MemoryLoadBytes should contain the values as described in the docs.

Actual behavior

GCMemoryInfo.MemoryLoadBytes contains MEMORYSTATUS.dwAvailPhys

Regression?

Not sure if this has ever worked. I haven't tried before.

Known Workarounds

Stay with the GetGlobalMemoryStatus API method.

Configuration

.NET7 / Visual Studio 2022

Other information

No response

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

Issue Details

---

Description

Irecently came across an issue where I wanted to get rid of the windows API method GetGlobalMemoryEx method and switch to the GC.GetMemoryInfo() to make my applications more platfom-independent.

From the description of the GCMemoryInfo it says for GCMemoryInfo.MemoryLoadBytes.

On Windows, memory load is a field in the MEMORYSTATUS structure. It's a number between 0 and 100 that specifies the approximate percentage of physical memory that's in use (0 indicates no memory use and 100 indicates full memory use). Corresponding information is given on other operating systems.

When looking at MEMORYSTATUS in https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus this seems to be correct. When I call the GC.GetMemoryInfo() though, the value in GCMemoryInfo.MemoryLoadBytes is not between 0 and 100.

Looking deeper in it, it seems more that the value contains MEMORYSTATUS.dwAvailPhys.

Is this a known behavior?

Reproduction Steps

Simply call GC.GetMemoryInfo() and compare to the corresponding windows GetGlobalMemoryStatus API call.

Expected behavior

GCMemoryInfo.MemoryLoadBytes should contain the values as described in the docs.

Actual behavior

GCMemoryInfo.MemoryLoadBytes contains MEMORYSTATUS.dwAvailPhys

Regression?

Not sure if this has ever worked. I haven't tried before.

Known Workarounds

Stay with the GetGlobalMemoryStatus API method.

Configuration

.NET7 / Visual Studio 2022

Other information

No response

Author:	msedi
Assignees:	-
Labels:	area-System.Memory
Milestone:	-

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

Issue Details

---

Description

Irecently came across an issue where I wanted to get rid of the windows API method GetGlobalMemoryEx method and switch to the GC.GetMemoryInfo() to make my applications more platfom-independent.

From the description of the GCMemoryInfo it says for GCMemoryInfo.MemoryLoadBytes.

On Windows, memory load is a field in the MEMORYSTATUS structure. It's a number between 0 and 100 that specifies the approximate percentage of physical memory that's in use (0 indicates no memory use and 100 indicates full memory use). Corresponding information is given on other operating systems.

When looking at MEMORYSTATUS in https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus this seems to be correct. When I call the GC.GetMemoryInfo() though, the value in GCMemoryInfo.MemoryLoadBytes is not between 0 and 100.

Looking deeper in it, it seems more that the value contains MEMORYSTATUS.dwAvailPhys.

Is this a known behavior?

Reproduction Steps

Simply call GC.GetMemoryInfo() and compare to the corresponding windows GetGlobalMemoryStatus API call.

Expected behavior

GCMemoryInfo.MemoryLoadBytes should contain the values as described in the docs.

Actual behavior

GCMemoryInfo.MemoryLoadBytes contains MEMORYSTATUS.dwAvailPhys

Regression?

Not sure if this has ever worked. I haven't tried before.

Known Workarounds

Stay with the GetGlobalMemoryStatus API method.

Configuration

.NET7 / Visual Studio 2022

Other information

No response

Author:	msedi
Assignees:	-
Labels:	area-GC-coreclr, untriaged
Milestone:	-

[msedi]

As a side-note: While experimenting further on this, it doesn't seem that the MemoryLoadBytes corresponds with MEMORYSTATUS.dwAvailPhys. Obviously there was a good match at the time of writing this. But now it isn't anymore.

[msedi]

Not sure, but maybe the same problem #94846

[mrahl]

Not sure, but maybe the same problem #94846

MemoryLoadBytes seems to be in bytes, just like TotalAvailableMemoryBytes and like the names of both indicate. We've been using it like that since .NET 5 days. #94846 is what seems like regression on this specifically on Mac. Completely agree that the remark about a value between 0 and 100 in the docs is confusing though.

[msedi]

@mrahl: Thanks. Yes, this was also my observation. So the docs need to be adapted.

[Maoni0]

the doc is definitely misleading at best - this is in bytes, so it's obviously not going to be between 0 and 100 like what we usually mean when we say physical memory load. this should be fixed.

what this field shows is if the process isn't running in a container with a memory limit, it's the physical memory in use; otherwise it's either the cgroup's physical memory in use or (if we can't get it on linux or if we are on windows) the current process's working set.

@msedi, you don't mean MEMORYSTATUS.dwAvailPhys right? this should be (MEMORYSTATUSEX.ullTotalPhys - MEMORYSTATUSEX.ullAvailPhys).