[mono][sgen] Prevent concurrent sweep from blocking major collections #98154
Conversation
ghost
assigned 
|
Tagging subscribers to this area: @BrzVlad Issue DetailsSweeping 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 collection 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. Fixes #97991
|
|
cc @pavelsavara. Haven't really tested wasm but I think it will fix. |
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
force-pushed
the
fix-sgen-major-while-sweep
branch
from
4b90a1b
to
97651e9
Compare
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 collection 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.
Fixes #97991