This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Don't compact LOH just because a heap_hard_limit exists #23366
Merged
Conversation
This file contains hidden or 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
This is based on a perf test with 100% survival in a container, before and after #22180. GC pause times were greater after that commit. Debugging showed that the reason was that after, we were always doing compacting GC, and objects were staying in generation 1 and not making it to generation 2. The reason was that in the "after" build, `should_compact_loh()` was always returning true if heap_hard_limit was set; currently if we do an LOH compaction, we compact all other generations too. As the comment indicates, we should decide that automatically, not just set it to true all the time.
ghost
requested a review
from 
|
|
Maoni0
approved these changes
Mar 20, 2019
|
@dotnet-bot test Ubuntu x64 Checked Innerloop Build and Test |
|
@dotnet-bot test Ubuntu arm Cross Checked no_tiered_compilation_innerloop Build and Test |
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
Don't compact LOH just because a heap_hard_limit exists Commit migrated from dotnet/coreclr@513ccfc
This pull request was closed.
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.
Don't compact LOH just because a heap_hard_limit exists
This is based on a perf test with 100% survival in a container, before
and after #22180. GC pause times were greater after that commit.
Debugging showed that the reason was that after, we were always doing
compacting GC, and objects were staying in generation 1 and not making it
to generation 2. The reason was that in the "after" build,
should_compact_loh()was always returning true if heap_hard_limit wasset; currently if we do an LOH compaction, we compact all other
generations too. As the comment indicates, we should decide that
automatically, not just set it to true all the time.