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
It was with some trepidation that we enabled the write barrier during the concurrent scan phase (commits 1303957 and b0532a9). At the time, this was the simplest way of fixing lost write barriers with stack barriers, but there's a big TODO in func gc about other ways to fix the problem.
While there are other solutions to this particular problem, enabling the write barrier earlier has another very important property: it lets us enable mutator assists during all concurrent phases of the GC. This is important for avoiding over-allocation. The other alternative is to block user goroutines when they allocate too much during concurrent scan, which runs contrary to the whole purpose of concurrent GC.
We should embrace enabling the write barrier during concurrent scan. We should clean up code that originally dealt with enabling write barriers later, such as the whole "install write barrier" step that no longer actually installs the write barrier. We should also start background marking during scan (there's effectively no difference between the scan and mark phases any more), which will also improve the performance of assists by building up background mark credit and probably simplify the state machine approach advanced by #11970.
It was with some trepidation that we enabled the write barrier during the concurrent scan phase (commits 1303957 and b0532a9). At the time, this was the simplest way of fixing lost write barriers with stack barriers, but there's a big TODO in func gc about other ways to fix the problem.
While there are other solutions to this particular problem, enabling the write barrier earlier has another very important property: it lets us enable mutator assists during all concurrent phases of the GC. This is important for avoiding over-allocation. The other alternative is to block user goroutines when they allocate too much during concurrent scan, which runs contrary to the whole purpose of concurrent GC.
We should embrace enabling the write barrier during concurrent scan. We should clean up code that originally dealt with enabling write barriers later, such as the whole "install write barrier" step that no longer actually installs the write barrier. We should also start background marking during scan (there's effectively no difference between the scan and mark phases any more), which will also improve the performance of assists by building up background mark credit and probably simplify the state machine approach advanced by #11970.
@RLH @rsc
The text was updated successfully, but these errors were encountered: