Fixing a bug that causes us to mistakenly demote a gen2 region to gen0 #82413
Conversation
We are seeing a gen0 region that's almost fully occupied (< 24 bytes free) with one giant plug (ie, no free objects at all in the region). This causes allocate_in_condemned_generations to go into an infinite loop because in ephemeral generations we expect short plugs, ie, we should be able to allocate a min free object in front of each plug. And normally we can because when we allocate objects in gen0 we make sure to break up the allocation contexts with min free objects and when we compact into gen1 we form short plugs. We are in this situation when all of the following conditions are true - + we did a gen2 compacting GC that generates a pinned plug in a gen2 region almost as big as the whole region. my guess for the reason why there's this giant pinned plug is because that gen2 region was already really compact so when we called allocate_in_condemned_generations on the non pinned plugs that are next to some pinned plugs in it we discovered we can't move the non pinned plugs anyway so we artificially pinned them and formed a giant pinned plug. and during this GC those objects were no longer pinned so we have one giant non pinned plug. + this gen2 region needs to be the last region with pinned plugs; + this gen2 region hasn't been consumed by allocate_in_condemned_generations yet so it was processed by process_remaining_regions; Then in process_remaining_regions we'll set the plan_gen_num for that gen2 region to 0 because we are doing set_region_plan_gen_num_sip (current_region, current_plan_gen_num); instead of going through the demotion logic to decide whether we should demote this region or not.
|
fixes #80073 |
| @@ -28876,7 +28876,8 @@ void gc_heap::process_remaining_regions (int current_plan_gen_num, generation* c | |||
| return; | |||
| } | |||
|
|
|||
| set_region_plan_gen_num_sip (current_region, current_plan_gen_num); | |||
| decide_on_demotion_pin_surv (current_region); | |||
There was a problem hiding this comment.
Looking at the code in decide_on_demotion_pin_surv, we may still set the generation to 0 if pinned survival is low enough. I thought that during this GC, the objects were no longer pinned, so pinned survival should be 0. So what am I missing?
There was a problem hiding this comment.
during this GC it's no longer pinned, but it was pinned in the last (gen2 compacting GC) which was why it was (mistakenly) demoted to a gen0 region. so in this GC, since it's no longer pinned, we are calling alloc_in_condemned on it.
There was a problem hiding this comment.
the purpose of the fix is for the last GC we would not have demoted this region to gen0. so in this GC, we wouldn't be calling alloc_in_condemned for a giant plug.
There was a problem hiding this comment.
Ah, I see - thanks for the explanation.
|
this does not fix another problem in however the other problem is only a problem when we can't get new regions in for backporting to 7.0 I think it's ok to just port this one as a fix for the other problem is much more involved. essentially we'd want to make sure during plan we keep our invariant which means we should keep track of how many regions are already planned in each condemened gen and when we demote, make sure we have at least one region in each gen if that's not the case. I'll let that fix bake in 8.0 for a while and see if we still need to backport. |
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4407773176 |
ghost
locked as resolved and limited conversation to collaborators
We are seeing a gen0 region that's almost fully occupied (< 24 bytes free) with one giant plug (ie, no free objects at all in the region). This causes allocate_in_condemned_generations to go into an infinite loop because in ephemeral generations we expect short plugs, ie, we should be able to allocate a min free object in front of each plug. And normally we can because when we allocate objects in gen0 we make sure to break up the allocation contexts with min free objects and when we compact into gen1 we form short plugs.
We are in this situation when all of the following conditions are true -
Then in process_remaining_regions we'll set the plan_gen_num for that gen2 region to 0 because we are doing
set_region_plan_gen_num_sip (current_region, current_plan_gen_num);
instead of going through the demotion logic to decide whether we should demote this region or not.