From b5b09cc9f905316ad3abd732c091d90b78fd7c90 Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Fri, 23 Aug 2024 11:35:57 -0700 Subject: [PATCH 1/5] Fixed documentation for MemoryLoadBytes --- xml/System/GCMemoryInfo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 5e760339101..9aee0df4000 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -316,7 +316,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is Gets the physical memory load when the last garbage collection occurred. The physical memory load, in bytes, when the last garbage collection occurred. - On Windows, memory load is a field in the [MEMORYSTATUS structure](/windows/win32/api/winbase/ns-winbase-memorystatus). 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. + On Windows, memory load is a field in the [MEMORYSTATUS structure](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus) in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. Otherwise, it's either the cgroup's physical memory in use or the current process' working set if we are on Windows or somehow can't obtain it from Linux. Corresponding information is given on other operating systems. Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly. From 81edcb3b1930573aced5103df47a010244a05186 Mon Sep 17 00:00:00 2001 From: "Mukund Raghav Sharma (Moko)" <68247673+mrsharm@users.noreply.github.com> Date: Fri, 23 Aug 2024 12:13:24 -0700 Subject: [PATCH 2/5] Update xml/System/GCMemoryInfo.xml Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- xml/System/GCMemoryInfo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 9aee0df4000..7aead7bda3a 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -316,7 +316,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is Gets the physical memory load when the last garbage collection occurred. The physical memory load, in bytes, when the last garbage collection occurred. - On Windows, memory load is a field in the [MEMORYSTATUS structure](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus) in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. Otherwise, it's either the cgroup's physical memory in use or the current process' working set if we are on Windows or somehow can't obtain it from Linux. Corresponding information is given on other operating systems. + On Windows, memory load is a field in the [MEMORYSTATUS structure](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus) in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. For other operating systems, or if the process is running on Windows in a container with a memory limit, memory load is either the cgroup's physical memory in use or the current process's working set. Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly. From d47ead9f3d30a1d25b461460fff2fe92d8392387 Mon Sep 17 00:00:00 2001 From: "Mukund Raghav Sharma (Moko)" <68247673+mrsharm@users.noreply.github.com> Date: Fri, 23 Aug 2024 13:07:26 -0700 Subject: [PATCH 3/5] Update xml/System/GCMemoryInfo.xml Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- xml/System/GCMemoryInfo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 7aead7bda3a..72e3f0beb38 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -316,7 +316,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is Gets the physical memory load when the last garbage collection occurred. The physical memory load, in bytes, when the last garbage collection occurred. - On Windows, memory load is a field in the [MEMORYSTATUS structure](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus) in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. For other operating systems, or if the process is running on Windows in a container with a memory limit, memory load is either the cgroup's physical memory in use or the current process's working set. + On Windows, memory load is a field in the MEMORYSTATUS structure in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. For other operating systems, or if the process is running on Windows in a container with a memory limit, memory load is either the cgroup's physical memory in use or the current process's working set. Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly. From 471fa1250df9b11d503f7292e6c7fadf570081df Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Wed, 11 Sep 2024 11:02:41 -0700 Subject: [PATCH 4/5] Addressed feedback --- xml/System/GCMemoryInfo.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 9aee0df4000..1c4c9bb7c66 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -316,7 +316,12 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is Gets the physical memory load when the last garbage collection occurred. The physical memory load, in bytes, when the last garbage collection occurred. - On Windows, memory load is a field in the [MEMORYSTATUS structure](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-memorystatus) in bytes that denotes the physical memory that's in use if the process isn't running in a container with a memory limit. Otherwise, it's either the cgroup's physical memory in use or the current process' working set if we are on Windows or somehow can't obtain it from Linux. Corresponding information is given on other operating systems. + When a process is not running in a container or running in a container without a memory limit: + On Windows, the MemoryLoadBytes is obtained from the MEMORYSTATUS structure in bytes divided by the total physical memory. + On Linux, the MemoryLoadBytes is obtained from reading the MemAvailable field from `/proc/meminfo` divided by the total physical memory. + When a process is running in a container with a memory limit: + On Windows, the MemoryLoadBytes is obtained from the PROCESS_MEMORY_COUNTERS structure in bytes divided by the memory limit. + On Linux, the MemoryLoadBytes is obtained from the used physical memory via the CGroup Memory Usage file from `/memory.usage_in_bytes` for CGroups v1 and `/memory.current` for CGroups v2 divided by the memory limit. Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly. From 4915fe40a95a5c3a9e290e585ed61041ec787c1a Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Thu, 12 Sep 2024 14:05:28 -0700 Subject: [PATCH 5/5] Addressed further feedback --- xml/System/GCMemoryInfo.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 1c4c9bb7c66..1c1c45a1f42 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -320,7 +320,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is On Windows, the MemoryLoadBytes is obtained from the MEMORYSTATUS structure in bytes divided by the total physical memory. On Linux, the MemoryLoadBytes is obtained from reading the MemAvailable field from `/proc/meminfo` divided by the total physical memory. When a process is running in a container with a memory limit: - On Windows, the MemoryLoadBytes is obtained from the PROCESS_MEMORY_COUNTERS structure in bytes divided by the memory limit. + On Windows, the MemoryLoadBytes is obtained from the Working Set Size field in the PROCESS_MEMORY_COUNTERS structure in bytes divided by the memory limit. On Linux, the MemoryLoadBytes is obtained from the used physical memory via the CGroup Memory Usage file from `/memory.usage_in_bytes` for CGroups v1 and `/memory.current` for CGroups v2 divided by the memory limit. Data is only brought into physical memory on first touch. If you allocated a big object but haven't actually used it, most of its memory isn't in physical memory. In this case, the allocation won't affect the memory load significantly.