-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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.
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
Reduce number of gen 2 GC under high memory load #83328
Reduce number of gen 2 GC under high memory load #83328
Conversation
Tagging subscribers to this area: @dotnet/gc Issue DetailsWe observed that under high memory load, we would sometimes get a blocking gen 2 collection right after a background gen 2 collection. The reason is that the background gen 2 collection finds free spaces which increase gen 2 fragmentation. The next collection sees this higher fragmentation and decides to compact gen 2 via a blocking collection. That in itself is not wrong, but it arguably happens too early. This PR changes the logic so we only check fragmentation in generation_to_condemn if we are about to do a gen 2 collection anyway, or we have observed growth in gen 2, implying that the fragmentation is no longer useful to fit objects from gen 1. There is a remaining issue that I have observed - sometimes
|
I agree - we should not be doing a blocking GC as sweeping - the cons outweigh the pros in this scenario. instead of setting settings.compaction to TRUE maybe it's easier for now to add a field to track the compacting decision by |
…ting of a decision by generation_to_condemn to trigger a full blocking collection. This addresses the case where we trigger a full blocking collection due to a high memory situation, but decide_on_compacting decides not to compact, but do mark and sweep.
I pushed a change adding an additional flag |
@Maoni0 is this still required or is it ok to close? |
since we haven't had time to test this, we can close for now and reopen when we have tested it. |
Closing for now. |
We observed that under high memory load, we would sometimes get a blocking gen 2 collection right after a background gen 2 collection.
The reason is that the background gen 2 collection finds free spaces which increase gen 2 fragmentation. The next collection sees this higher fragmentation and decides to compact gen 2 via a blocking collection. That in itself is not wrong, but it arguably happens too early.
This PR changes the logic so we only check fragmentation in generation_to_condemn if we are about to do a gen 2 collection anyway, or we have observed growth in gen 2, implying that the fragmentation is no longer useful to fit objects from gen 1.
There is a remaining issue that I have observed - sometimes
generation_to_condemn
decides to do a blocking collection in order to compact, but thendecide_on_compacting
decides not to compact because fragmentation isn't high enough. The end result is that we payed the cost of a blocking collection, but don't get the benefit. Arguably this needs fixing - perhaps we should just havegeneration_to_condemn
set thesettings.compaction
flag and only calldecide_on_compacting
if the flag is not already set.