You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mark termination does not have to rescan stacks that haven’t executed since the last scan and it doesn’t have to rescan above the lowest stack barrier. But a lot can happen between concurrent scan and mark termination that leaves mark termination with a lot of stack scanning work. We should think about how we can reduce this.
One way is to rescan stacks toward the end of the concurrent mark phase (perhaps as part of entering mark 2) to close the gap during which stacks can become dirty.
Another possibility (suggested by @RLH) is to rescan stacks on preemption. A potential downside of this is that a goroutine can be preempted many times during concurrent mark, and ultimately only the most recent scan matters. It may also cause us to retain more floating garbage.
The text was updated successfully, but these errors were encountered:
Mark termination does not have to rescan stacks that haven’t executed since the last scan and it doesn’t have to rescan above the lowest stack barrier. But a lot can happen between concurrent scan and mark termination that leaves mark termination with a lot of stack scanning work. We should think about how we can reduce this.
One way is to rescan stacks toward the end of the concurrent mark phase (perhaps as part of entering mark 2) to close the gap during which stacks can become dirty.
Another possibility (suggested by @RLH) is to rescan stacks on preemption. A potential downside of this is that a goroutine can be preempted many times during concurrent mark, and ultimately only the most recent scan matters. It may also cause us to retain more floating garbage.
The text was updated successfully, but these errors were encountered: