[GC] Handle growing global_regions_to_decommit lists #106168
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nd to ensure it is done
|
Tagging subscribers to this area: @dotnet/gc |
This was referenced Aug 9, 2024
Open
markples
changed the title
markples
added a commit
to markples/runtime
that referenced
this pull request
Aug 14, 2024
markples
added a commit
that referenced
this pull request
Aug 16, 2024
) In #105521, the number of regions to be decommitted can be reduced, but the budgets weren't updated to include the new regions. This was fine for huge regions, which just sit in the global free list anyway, and it (sort of) works in release builds (though some regions may end up decommitted anyway if they are still in the surplus list at the end of distribution), but it isn't the intended behavior and can trigger a debug assertion that the surplus list is empty. This change (a subset of #106168), restructures distribute_free_regions so that instead of "decommit or adjust budgets", we first decommit and adjust the remaining balance. Then we adjust budgets based on the new value.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some cases, we can add items to the decommit list faster that we're willing to decommit them. Decommit is throttled to avoid potentially long pauses. In these cases, instead of continuing to add items to the decommit list, we can artificially inflate our budgets since the memory is already committed.
One advantage of this fix late in the product cycle is that it only changes behavior if the decommit list is non-empty at the start of a GC. A disadvantage is that capping the new decommit list at the size of the previous amount decommitted is fairly arbitrary and doesn't account for differing times between GCs. We could use different amounts or try to track more history, but also an incorrect amount will just lead to more/less memory on the decommit list until it is recalculated at the next GC anyway.
This also imposes an absolute cap on the decommit list size.
This is an alternate fix to #87715