Make sure the initial mark list size is capped #76083
Merged
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.
Fixes #75538
Part of the reason that we have a large working set when running on a machine with 64GB of memory is because of our mark list initial size logic.
The existing logic:
For workstation GC, the initial size is computed by setting it to a number proportional to
soh_segment_size
. The heuristic is that if you happen to have a large segment size, then you will probably have more surviving objects, so you will need a larger mark list.Later on, it is possible that we hit a mark list overflow, and in that case, we will grow the mark list. The mark list has to be sorted, so we have a cap on the mark list size to ensure we don't have a huge mark list and spend all our time sorting.
The flaw:
Since we have the capability to grow the mark list, there is no need for us to create a big one up front. Also, since the
grow_mark_list
have the logic to cap the mark list size, it doesn't make sense for us to have an initial size bigger than the cap.The fix:
I extracted the logic to compute the cap as a helper function, then I can use the same cap to limit the initial size computation.
The benefits:
By reducing the mark list size, we will always use less memory. The reduced mark list size should also cap the sorting time. Without this fix, we could be sorting large lists, but now it is impossible.
The risk:
A reduced mark list size may not be able to store all survived objects, and in such cases, the
plan_phase
needs to walk all the objects, survived or not, and that could potentially be a regression. For that to happen, one must have quite a bit of survived objects, but also not survive a high percentage such that walking the free objects is an issue. IMO, this should be quite unlikely.