-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[mono][sgen] Fix incorrect condition when checking if we should do a major collection #120432
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
Conversation
…major collection When we are in this method, major sweep hasn't yet finished so we check with some imprecise conservative values. min_heap_size is a conservative lower limit of the actual heap size. Allowance represents how much more we allow the heap to grow after the previous major collection. We were comparing the min_heap_size with the allowance by mistake, when we should have compared it with the next major trigger size (which is the heap_size after the last collection plus the allowance).
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 PR fixes an incorrect condition in the Mono SGEN garbage collector that was causing excessive major garbage collections. The bug was introduced in a previous change and resulted in performance regression from .NET 8 to .NET 9.
Key changes:
- Corrects the major collection trigger logic by comparing minimum heap size against the proper threshold
- Fixes a condition that was incorrectly comparing heap size with allowance instead of total trigger size
|
Tagging subscribers to this area: @BrzVlad |
lateralusX
left a comment
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.
LGTM!
|
/ba-g wasm unrelated |
|
/backport to release/10.0 |
|
Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/18348341019 |
|
/backport to release/9.0-staging |
|
Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/18348346199 |
…we should do a major collection (#120532) Backport of #120432 to release/10.0 /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally This impacts all platforms using mono. A customer reported a 40x regression on an XML Serialization benchmark when moving from .NET8 to .NET9. This regression is caused by the runtime triggering excessive GCs due to a bug in the heuristic. This is more likely to happen if the GC concurrent sweep phase takes longer and the application allocates large objects frequently. This likely impacts many applications, but with less noticeable performance impact. ## Regression - [x] Yes - [ ] No This regressed in .NET9 ## Testing Tested the fix on sample benchmark that it works correctly. ## Risk Low risk. The fix is localized and the previous condition was blatantly wrong by mistake. Co-authored-by: Vlad Brezae <[email protected]>
When we are in this method, major sweep hasn't yet finished so we check with some imprecise conservative values. min_heap_size is a conservative lower limit of the actual heap size. Allowance represents how much more we allow the heap to grow after the previous major collection. We were comparing the min_heap_size with the allowance by mistake, when we should have compared it with the next major trigger size (which is the heap_size after the last collection plus the allowance).
Wrong condition added in #98154, causing excessive GCs in some scenarios and regression from .net8 to .net9.
Fixes #119580