Commit 1caec12a authored by Jon Coppeard's avatar Jon Coppeard
Browse files

Bug 1818781 - Mark delayed children when doing background marking during sweep... 

Bug 1818781 - Mark delayed children when doing background marking during sweep phase r=sfink, a=dsmith

The problem is that the parallel marking work moved the delayed marking list
from GCMarkers to the GCRuntime, since there was only one list and there can
now be multiple markers. However the check for marking in
GCRuntime::markDuringSweeping wasn't updated so we skip the delayed marking in
this case.

For this to happen we have to OOM expanding the mark stack during sweep marking
and then run out of marking budget at exactly the point at which the mark stack
is empty. Then on the next slice we will miss the fact that there is delayed
marking work. This is pretty unlikely to occur and hard to arrange, as the bug
description shows.

Differential Revision: https://phabricator.services.mozilla.com/D173170
parent 10c2b0d4

js/src/gc/Sweeping.cpp

+1 −1
Original line number Diff line number Diff line
@@ -1678,7 +1678,7 @@ IncrementalProgress GCRuntime::markDuringSweeping(JS::GCContext* gcx, 
  MOZ_ASSERT(markTask.isIdle());



  if (markOnBackgroundThreadDuringSweeping) {

    if (!marker().isDrained()) {

    if (!marker().isDrained() || hasDelayedMarking()) {

      AutoLockHelperThreadState lock;

      MOZ_ASSERT(markTask.isIdle(lock));

      markTask.setBudget(budget);