Skip to content

Commit ce8f49e

Browse files
authored
don't call GetHeap to get the heap in wait_for_gc_done (dotnet#107073)
we see the assert in GCHeap::GetHeap when called by wait_for_gc_done - GCHeap* GCHeap::GetHeap (int n) { assert (n < gc_heap::n_heaps); return gc_heap::g_heaps[n]->vm_heap; } when HC change is in progress and we are reducing the HC. this assert is actually unnecessary when called by wait_for_gc_done but is necessary when called by other methods like balance_heaps (those are in coop mode so they cannot observe the HC transition). so I just changed to getting the heap from g_heaps instead of calling GetHeap. previously I thought this could actually be a functional problem but after doing more thinking I think this is just a benign assert. if we are observing the transition from the old HC to the new HC in wait_for_gc_done and we happen to be waiting on a heap that's decommissioned, decommission_heap sets its heap's gc_done_event so what will happen is wait_for_gc_done will wake up from waiting as soon decommission_heap is executed. at this time n_heaps is also updated. so when it gets to the next iteration in the while loop it will get a valid heap's gc_done_event to wait on.
1 parent 66b9b68 commit ce8f49e

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/coreclr/gc/gc.cpp

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14787,7 +14787,7 @@ gc_heap::wait_for_gc_done(int32_t timeOut)
1478714787
while (gc_heap::gc_started)
1478814788
{
1478914789
#ifdef MULTIPLE_HEAPS
14790-
wait_heap = GCHeap::GetHeap(heap_select::select_heap(NULL))->pGenGCHeap;
14790+
wait_heap = g_heaps[heap_select::select_heap(NULL)];
1479114791
dprintf(2, ("waiting for the gc_done_event on heap %d", wait_heap->heap_number));
1479214792
#endif // MULTIPLE_HEAPS
1479314793

0 commit comments

Comments
 (0)