From b5b09cc9f905316ad3abd732c091d90b78fd7c90 Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Fri, 23 Aug 2024 11:35:57 -0700 Subject: [PATCH 01/10] 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 02/10] 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. + 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 05/10] 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. From 59ff63aa6aebbe5aa3890ea6f4b76ef35a1e3eb1 Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Mon, 21 Jul 2025 08:37:10 -0700 Subject: [PATCH 06/10] Added more cases --- xml/System/GCMemoryInfo.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 59eb35ad801..7d1d113a28d 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -319,9 +319,11 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is 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: + When a process is running in a container with a memory limit or when cgroup limits are set: 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. + 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. The cgroup limits don't necessarily mean there is a container. You can use cgroup to set limits on a regular process. + On Linux, when there is no cgroup enabled, the used physical memory is read from the `/proc/statm` file, which provides the process resident set size. + On Linux, the virtual memory load is also used if the virtual memory rlimit is set and if the load is larger than the physical memory load. 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 4cff0251189f61d3c746a54450d2baf24a582c77 Mon Sep 17 00:00:00 2001 From: Mukund Raghav Sharma Date: Fri, 25 Jul 2025 07:56:15 -0700 Subject: [PATCH 07/10] Addressed 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 59eb35ad801..2e372b2a786 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -321,7 +321,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is 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 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. + 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 0aefe85b6c1a89d859bcc1361622b772137c7601 Mon Sep 17 00:00:00 2001 From: "Mukund Raghav Sharma (Moko)" <68247673+mrsharm@users.noreply.github.com> Date: Mon, 28 Jul 2025 16:08:30 -0700 Subject: [PATCH 08/10] 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 9ca4f693a91..6499099fad4 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -322,7 +322,7 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is When a process is running in a container with a memory limit or when cgroup limits are set: 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. The cgroup limits don't necessarily mean there is a container. You can use cgroup to set limits on a regular process. - On Linux, when there is no cgroup enabled, the used physical memory is read from the `/proc/statm` file, which provides the process resident set size. + On Linux, when there is no cgroup enabled, the used physical memory is read from the /proc/statm file, which provides the process resident set size. On Linux, the virtual memory load is also used if the virtual memory rlimit is set and if the load is larger than the physical memory load. 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 b10a7f68da468dae92cdd9e2771abe39e829dcee Mon Sep 17 00:00:00 2001 From: "Mukund Raghav Sharma (Moko)" <68247673+mrsharm@users.noreply.github.com> Date: Mon, 28 Jul 2025 16:08:37 -0700 Subject: [PATCH 09/10] Update xml/System/GCMemoryInfo.xml Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- xml/System/GCMemoryInfo.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 6499099fad4..98ee27d856b 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -316,9 +316,9 @@ 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. - 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 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 or when cgroup limits are set: 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. The cgroup limits don't necessarily mean there is a container. You can use cgroup to set limits on a regular process. From 8c7607239ec2e6d72a05d051facdc1674cbf3826 Mon Sep 17 00:00:00 2001 From: "Mukund Raghav Sharma (Moko)" <68247673+mrsharm@users.noreply.github.com> Date: Mon, 28 Jul 2025 16:09:07 -0700 Subject: [PATCH 10/10] Update xml/System/GCMemoryInfo.xml Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- xml/System/GCMemoryInfo.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xml/System/GCMemoryInfo.xml b/xml/System/GCMemoryInfo.xml index 98ee27d856b..47c35e06ba7 100644 --- a/xml/System/GCMemoryInfo.xml +++ b/xml/System/GCMemoryInfo.xml @@ -319,9 +319,9 @@ The memory after `OBJ_D` is not considered part of the `FragmentedBytes` but is 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 or when cgroup limits are set: - 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. The cgroup limits don't necessarily mean there is a container. You can use cgroup to set limits on a regular process. + When a process is running in a container with a memory limit or when cgroup limits are set: + - 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. The cgroup limits don't necessarily mean there is a container. You can use cgroup to set limits on a regular process. On Linux, when there is no cgroup enabled, the used physical memory is read from the /proc/statm file, which provides the process resident set size. On Linux, the virtual memory load is also used if the virtual memory rlimit is set and if the load is larger than the physical memory load. 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. pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.

Alternative Proxies: