Making sure we have at least one region per gen during plan phase by Maoni0 · Pull Request #83076 · dotnet/runtime

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

Maoni0 · 2023-03-07T08:23:30Z

Currently we can get into the situation that we didn't have at least one region in each generation we
need to plan. And most of the time we are getting away with it because we can just get a new region
in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our
at least one region per generation invariant.

This change keeps how many regions are planned in each generation and if needed we will attempt to get
new regions during plan phase. And if we can't we will go into the special sweep mode.

When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be
freely planned into any generation we need. We could actually plan regions with only pinned surv to
any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards
on those pinned objects because we will not have a chance later. The benefit of doing this is small
in general as when we get into process_remaining_regions, it's rare we don't already have planned regions
in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

ghost · 2023-03-07T08:23:42Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author:	Maoni0
Assignees:	-
Labels:	`area-GC-coreclr`
Milestone:	-

Currently we can get into the situation that we didn't have at least one region in each generation we need to plan. And most of the time we are getting away with it because we can just get a new region in thread_final_regions. But if we can't, it's a functional problem because we will not maintain our at least one region per generation invariant. This change keeps how many regions are planned in each generation and if needed we will attempt to get new regions during plan phase. And if we can't we will go into the special sweep mode. When we demote regions with only pinned surv, we detect the ones with no surv at all - those can be freely planned into any generation we need. We could actually plan regions with only pinned surv to any generation, eg, we could promote a gen0 region to gen2. However it means we'd need to set cards on those pinned objects because we will not have a chance later. The benefit of doing this is small in general as when we get into process_remaining_regions, it's rare we don't already have planned regions in higher generations. So I don't think it's worth the complexicity for now. We may consider it for the future.

Maoni0 · 2023-04-15T01:55:12Z

/azp run runtime-coreclr outerloop

azure-pipelines · 2023-04-15T01:55:30Z

Azure Pipelines successfully started running 1 pipeline(s).

PeterSolMS

Looks good to me.

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

ghost added the area-GC-coreclr label Mar 7, 2023

ghost assigned Maoni0 Mar 7, 2023

Maoni0 added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 7, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch 2 times, most recently from 401d828 to 82c114cCompare April 13, 2023 07:30

Maoni0 changed the title ~~WIP reworked how the demotion logic should work in process_remaining_regions~~Making sure we have at least one region per gen during plan phaseApr 13, 2023

Maoni0 removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 13, 2023

Maoni0 force-pushed the fix_hang_80073_fix2 branch from 82c114c to 167966fCompare April 13, 2023 07:44

PeterSolMS reviewed Apr 13, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gcpriv.h Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp Outdated

PeterSolMS reviewed Apr 18, 2023
View reviewed changes

Comment threadsrc/coreclr/gc/gc.cpp

PeterSolMS approved these changes Apr 18, 2023
View reviewed changes

address cr feedback
789aae3

Maoni0 merged commit 71d7f4b into dotnet:mainApr 22, 2023

ghost locked as resolved and limited conversation to collaborators May 22, 2023

Uh oh!

Conversation

Maoni0 commented Mar 7, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Mar 7, 2023

Uh oh!

Uh oh!

Maoni0 commented Apr 15, 2023

Uh oh!

azure-pipelinesBot commented Apr 15, 2023

Uh oh!

Uh oh!

Uh oh!

PeterSolMS left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Maoni0 commented Mar 7, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Mar 7, 2023

Uh oh!

Uh oh!

Maoni0 commented Apr 15, 2023

Uh oh!

azure-pipelinesBot commented Apr 15, 2023

Uh oh!

Uh oh!

Uh oh!

PeterSolMS left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Maoni0 commented Mar 7, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Mar 7, 2023

Uh oh!

Uh oh!

Maoni0 commented Apr 15, 2023

Uh oh!

azure-pipelinesBot commented Apr 15, 2023

Uh oh!

Uh oh!

Uh oh!

PeterSolMS left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Maoni0 commented Mar 7, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Maoni0 commented Mar 7, 2023•
edited
Loading

Maoni0 commented Mar 7, 2023•
edited
Loading

Maoni0 commented Mar 7, 2023•
edited
Loading

Maoni0 commented Mar 7, 2023•
edited
Loading

Maoni0 commented Mar 7, 2023•
edited
Loading