Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[mono][sgen] Prevent concurrent sweep from blocking major collections #98154

Merged
merged 1 commit into from
Feb 9, 2024
Merged

[mono][sgen] Prevent concurrent sweep from blocking major collections #98154

merged 1 commit into from
Feb 9, 2024

Commits on Feb 8, 2024

  1. [mono][sgen] Prevent concurrent sweep from blocking major collections 

    Sweeping is the final GC stage, that does a final iteration on the memory in order to prepare internal data structures for future allocation, free memory etc. For large objects this is done during GC while for small objects it can be done concurrently with the mutator, after we resume the world. We attempt to trigger the next major collectio when the heap grows with another third of its size at the moment of the last collection. This heap limit is the major trigger size and it can only be computed after the sweep job has finished. This is because sweep iterates each major block to determine if they have any marked objects, attempting to free the blocks if possible.

Because there is a dependency for setting the major trigger size on the sweep job completion, before this change we were just blocking any new major collections to happen if concurrent sweep wasn't finished. This means that if the sweep job takes longer than expected and the mutator does excessive allocation in short amount of time, the memory usage can increase aggresively. It is unclear how relevant this scenario is in practice, but it is easy to reproduce in a micro benchmark allocating large objects.

The fix relies on computing estimates for the current heap size and the soon to be computed trigger size. We estimate the current live number of major blocks by adding the number of major blocks allocated since the last collection to the number of blocks already traversed and determined to be live by sweep. This estimate will be a lower limit. We determine the number of major blocks during the previous collection by subtracting the number of major blocks before sweep starts by the number of blocks already traversed and determined to be free. This estimate will be an upper limit. If the lower limit of the current heap size exceeds the upper limit of the trigger size, then there is no point in waiting for sweep to finish. We know we will require a major collection.
    @BrzVlad
    BrzVlad committed Feb 8, 2024
    Configuration menu
    Copy the full SHA
    97651e9 View commit details
    Browse the repository at this point in the history