-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Throttle finalization a bit when doing GC stress. #118879
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
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
Azure Pipelines successfully started running 2 pipeline(s). |
The effect of this change on
I suspect, but do not have direct evidence, that the change has higher effect on arm64 platforms because we issue more process-wide barriers per GC. I do not have a good explanation why 32bit tests are not affected. |
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
Azure Pipelines successfully started running 2 pipeline(s). |
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
Azure Pipelines successfully started running 2 pipeline(s). |
I have run GC stress once more. It looks like results are repeatable. |
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 addresses performance issues during GC stress testing by throttling the finalization rate to prevent continuous occupation of the finalizer loop. The change replaces the existing quiescence-based approach with a simple time-based throttling mechanism that limits finalization to approximately 1 item per millisecond when running under GC stress levels greater than 1.
Key changes:
- Replace the existing GC quiescence-based throttling with a simpler sleep-based approach
- Move throttling logic from the main finalizer worker loop to occur per finalized object
- Reduce overhead from continuous GC count checking and thread switching
There was a failure in second try. Not sure if related. |
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
Azure Pipelines successfully started running 2 pipeline(s). |
Lots of new failures, which seem unrealted to the change. Things seems to be quite broken now. Example:
Another:
|
/azp run runtime-coreclr gcstress-extra, runtime-coreclr gcstress0x3-gcstress0xc |
Azure Pipelines successfully started running 2 pipeline(s). |
#119028 has the fix for this one. |
I have tried combining this PR with the fix and nearly everything passed. - see: #119037 There were some failures on arm32, but I did not see any failures in the previous runs with this PR, so I assume they are not related to this change. |
This is a test-only change that so far was not found to cause regressions. |
/backport to release/10.0 |
Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/17196515733 |
Re: #114581
It looks like under GC stress a couple of self-rearming GC-finalizer callbacks can keep finalizer loop continuously occupied by re-arming each other and causing a GC. That adds very little to the coverage, but can consume considerable resources through frequent GCs and make everything else slower.
Throttling finalization rate to 1 item/msec when running with GC stress reduces the rate of uninteresting GCs and makes the tests move faster.