Skip to content

Fix computing available memory on OSX for GC - #97102

Merged
janvorli merged 2 commits into
dotnet:mainfrom
janvorli:fix-osx-memory-load-report
Jan 25, 2024
Merged

Fix computing available memory on OSX for GC#97102
janvorli merged 2 commits into
dotnet:mainfrom
janvorli:fix-osx-memory-load-report

Conversation

@janvorli

Copy link
Copy Markdown
Member

We were using the vm_statistics_data_t::free_count as the available memory reported to the GC. It turned out this value is only a small portion of the available memory and that the appropriate value should be based on the kern.memorystatus_level value obtained using sysctl. That value represents percentual amount of available memory, so multiplying it by the total memory bytes gets the available memory bytes.

Close#94846

We were using the `vm_statistics_data_t::free_count` as the available memory
reported to the GC. It turned out this value is only a small portion of the
available memory and that the appropriate value should be based on the
kern.memorystatus_level value obtained using sysctl. That value represents percentual
amount of available memory, so multiplying it by the total memory bytes gets
the available memory bytes.
Closedotnet#94846
@janvorlijanvorli added this to the 9.0.0 milestone Jan 17, 2024
@janvorli
janvorli requested a review from Maoni0January 17, 2024 14:17
@janvorlijanvorli self-assigned this Jan 17, 2024
@ghost

Copy link
Copy Markdown

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

Issue Details

We were using the vm_statistics_data_t::free_count as the available memory reported to the GC. It turned out this value is only a small portion of the available memory and that the appropriate value should be based on the kern.memorystatus_level value obtained using sysctl. That value represents percentual amount of available memory, so multiplying it by the total memory bytes gets the available memory bytes.

Close #94846

Author:janvorli
Assignees:janvorli
Labels:

area-GC-coreclr

Milestone:9.0.0

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated
int rc = sysctlnametomib(mem_free_name, NULL, &g_kern_memorystatus_level_mib_length);
if (rc == 0)
{
g_kern_memorystatus_level_mib = (int*)malloc(g_kern_memorystatus_level_mib_length * sizeof(int));

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

presumably if this returns null then sysctlnametomib would return a failure?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for spotting the missing check, fixed.

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated
if (KERN_SUCCESS == host_page_size(mach_port, &page_size))
uint32_t mem_free = 0;
size_t mem_free_length = sizeof(uint32_t);
if (g_kern_memorystatus_level_mib != NULL)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if GCToOSInterface::Initialize succeeded, this should always be non null, correct? if so we can just assert.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated
int64_t mem_size = 0;
size_t mem_size_length = sizeof(int64_t);
int mib[] = { CTL_HW, HW_MEMSIZE };
rc = sysctl(mib, 2, &mem_size, &mem_size_length, NULL, 0);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to get the total memory every time?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I've moved it to the init and also unified it with other total memory computations we had above.

@janvorli
janvorliforce-pushed the fix-osx-memory-load-report branch from 31809d5 to a5bf5dfCompareJanuary 19, 2024 13:51

@Maoni0Maoni0 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@janvorli
janvorli merged commit ffc1174 into dotnet:mainJan 25, 2024
@janvorli
janvorli deleted the fix-osx-memory-load-report branch January 25, 2024 01:30
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Feb 24, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GcMemoryInfo returns incorrect values in .NET 8 on macOS 14 Sonoma

2 participants

@janvorli@Maoni0