-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Enable GC Regions on Mac #115251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable GC Regions on Mac #115251
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This pull request attempts to re-enable regions on Mac by modifying the preprocessor condition.
- Removed the APPLE exclusion from the condition for defining USE_REGIONS
- Adjusted the code responsible for enabling regions on 64-bit systems
Tagging subscribers to this area: @dotnet/gc |
It is ok to try and the CI may even pass if the run does not happen to generate crash dump along the way. We need a positive confirmation that enabling regions GC won't kill post-mortem diagnostic on mac. Have we done anything to resolve the problem with prohibitively large crash dumps on mac? |
the last time we looked we werent able to repro the large dumps locally. Believe @janvorli had tried it too, given lower priority we never investigated it completely. Hoping we get to root cause this time around. |
I have validated that with large memory reservation size with regions the dump generated on MacOS is about 100mb larger (so it's only about 2% more) -- not order of magnitude larger we thought it would be. Need to figure out failures in iOS/tvOS NativeAOT failures before we can enable. |
excluding iOS and tvOS seems to get things to work. Will need to figure out if reducing the reservation size would get regions to work on those platforms too. |
@@ -140,11 +140,11 @@ inline void FATAL_GC_ERROR() | |||
// | |||
// This means any empty regions can be freely used for any generation. For | |||
// Server GC we will balance regions between heaps. | |||
// For now disable regions for standalone GC and macOS builds | |||
// For now disable regions for standalone GC and iOS and tvOS builds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// For now disable regions for standalone GC and iOS and tvOS builds | |
// For now disable regions for iOS and tvOS builds |
might as well take this opportunity to fix this comment since we do have a standalone GC with regions.
@@ -22,7 +22,7 @@ static int Main() | |||
|
|||
long lowerBound, upperBound; | |||
lowerBound = 1200 * 1024; // ~1.2 MB | |||
upperBound = 1600 * 1024; // ~1.6 MB | |||
upperBound = 1700 * 1024; // ~1.7 MB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the reason for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test checks for size_on_disk of the test binary. Regions adds more code which puts it over the test threshold.
I do not think this is a good plan. Analyzing failures and debugging iOS/tvOS is much harder than debugging macOS. If a segments-specific issue gets introduced in the meantime, it will be a lot harder and much more time consuming to diagnose it. |
ok, will investigate failures and enable for them too. |
// If no hard_limit is configured the reservation size is min of 1/2 GetVirtualMemoryLimit() or max of 256Gb or 2x physical limit. | ||
gc_heap::regions_range = max((size_t)256 * 1024 * 1024 * 1024, (size_t)(2 * gc_heap::total_physical_mem)); | ||
#else // MUTLIPLE_HEAPS | ||
// If no hard_limit is configured the reservation size is min of 1/2 GetVirtualMemoryLimit() or max of 256Gb or 2x physical limit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update the comment?
on my local testing looks like reservation of 1/4th of physical memory seems to succeed.
#else // MUTLIPLE_HEAPS | ||
#if defined(TARGET_IOS) || defined(TARGET_TVOS) | ||
// On iOS and tvOS only try to reserve 1/4 of physical memory | ||
gc_heap::regions_range = (size_t)(gc_heap::total_physical_mem / 4); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
physical_mem / 4
was required to get the iOS sample to work on my device. That works for CI as well. Haven't found any specific guidance online around specific policy here. CoPilot claims 2x to 4x reservation should be allowed on iOS but that doesn't seem to be the case. @vitek-karas, any guidance here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much is physical_mem / 4
in absolute numbers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://alwaysprocessing.blog/2022/02/20/size-matters is a great description of iOS virtual address space limitations. The available address space is limited and precious, very similar to the situation on 32-bit OSes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
physical_mem / 4
I expect that this number will be even lower for real world apps that load a bunch of libraries and occupy/fragment the address space further. iOS does some address space randomization, so the exact size of the largest block of memory that we are able to reserve will differ from run to run. And if we reserve too big of a block, other parts of the app may run into out of memory errors while there is a plenty of memory available.
I think it means that we should treat iOS as 32-bit OS when it comes to memory reservations. Unless we figure out how to make regions GC work well on 32-bit OSes, we should probably keep using segments GC on iOS, maybe even lower default segment size to make it work more like 32-bit OS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much is
physical_mem / 4
in absolute numbers?
on my iPhone 16 Pro its 2gb
(8gb total physical memory). Agree that we should keep iOS on segments for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then the question is whether we want to keep macOS on segments too to get a real-world test coverage for segments on 64-bit architectures in an easy to diagnose environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a strong preference since Mac has always been on segments. However, given the overall memory policy differences do we feel that iOS specific issues would be repro-able on Mac to help with diagnosing?
closing this PR for now, given the challenges with iOS probably reasonable to leave Apple platforms on segments for now. We will evaluate again if there is a strong case of regions helping on MacOS. |
Regions will be enabled for macOS, but still disabled for iOS and tvOS builds for now (will investigate the test failures on those platforms and try to enable in subsequent PRs).