-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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 double reporting detection #107986
base: main
Are you sure you want to change the base?
Conversation
This change adds detection of double reporting of stack slots and registers during GC stack walk. The detection is disabled by default and can be enabled using the DOTNET_EnableGCHoleMonitoring env variable. If a double reporting is found, it triggers an assert in both release and debug builds of the runtime.
Tagging subscribers to this area: @dotnet/gc |
Should this be on by default for GC stress runs? |
@@ -278,6 +278,7 @@ CONFIG_STRING_INFO(INTERNAL_SkipGCCoverage, W("SkipGcCoverage"), "Specify a list | |||
RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_StatsUpdatePeriod, W("StatsUpdatePeriod"), 60, "Specifies the interval, in seconds, at which to update the statistics") | |||
RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_GCRetainVM, W("GCRetainVM"), 0, "When set we put the segments that should be deleted on a standby list (instead of releasing them back to the OS) which will be considered to satisfy new segment requests (note that the same thing can be specified via API which is the supported way)") | |||
RETAIL_CONFIG_DWORD_INFO(EXTERNAL_gcAllowVeryLargeObjects, W("gcAllowVeryLargeObjects"), 1, "Allow allocation of 2GB+ objects on GC heap") | |||
RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_EnableGCHoleMonitoring, W("EnableGCHoleMonitoring"), 0, "Enable checks to proactively watch for possible GC holes") |
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.
Perhaps we can enable it some of the GC tests?
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.
I have just added a change that enables it also when GC stress is enabled, as @jkotas has suggested. So all the CI runs with GC stress will automatically execute this stuff.
@@ -201,7 +203,9 @@ static void ScanStackRoots(Thread * pThread, promote_func* fn, ScanContext* sc) | |||
#if defined(FEATURE_EH_FUNCLETS) | |||
flagsStackWalk |= GC_FUNCLET_REFERENCE_REPORTING; | |||
#endif // defined(FEATURE_EH_FUNCLETS) | |||
gcctx.pScannedSlots = new SetSHash<Object**, PtrSetSHashTraits<Object**> >(); |
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.
I'd prefer to see this not allocate at all unless duplicate detection is turned on. The performance impact doesn't really concern me, but it's just an extra opportunity for a process that is nearly out of memory to get an unlucky OOM in a new and horrible place, as I don't know think flowing a threw this code during the middle of a GC will leave the GC in a consistent state. Alternatively, you could do a nothrow'ing new, and have a null check around the use of the pScannedSlot variable.
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.
Sigh, my mistake, that was not intended. Happened accidentally by transforming the previous state of the PR to the current one.
This change adds detection of double reporting of stack slots and registers during GC stack walk. The detection is disabled by default and can be enabled using the DOTNET_EnableGCHoleMonitoring env variable.
If a double reporting is found, it triggers an assert in both release and debug builds of the runtime.