• Austin Clements's avatar
    runtime: generally allow preemption during concurrent GC phases · af060c30
    Austin Clements authored
    Currently, the entire GC process runs with g.m.preemptoff set. In the
    concurrent phases, the parts that actually need preemption disabled
    are run on a system stack and there's no overall need to stay on the
    same M or P during the concurrent phases. Hence, move the setting of
    g.m.preemptoff to when we start mark termination, at which point we
    really do need preemption disabled.
    
    This dramatically changes the scheduling behavior of the concurrent
    mark phase. Currently, since this is non-preemptible, concurrent mark
    gets one dedicated P (so 1/GOMAXPROCS utilization). With this change,
    the GC goroutine is scheduled like any other goroutine during
    concurrent mark, so it gets 1/<runnable goroutines> utilization.
    
    You might think it's not even necessary to set g.m.preemptoff at that
    point since the world is stopped, but stackalloc/stackfree use this as
    a signal that the per-P pools are not safe to access without
    synchronization.
    
    Change-Id: I08aebe8179a7d304650fb8449ff36262b3771099
    Reviewed-on: https://go-review.googlesource.com/8839Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
    af060c30
Name
Last commit
Last update
api Loading commit data...
doc Loading commit data...
lib/time Loading commit data...
misc Loading commit data...
src Loading commit data...
test Loading commit data...
.gitattributes Loading commit data...
.gitignore Loading commit data...
AUTHORS Loading commit data...
CONTRIBUTING.md Loading commit data...
CONTRIBUTORS Loading commit data...
LICENSE Loading commit data...
PATENTS Loading commit data...
README.md Loading commit data...
favicon.ico Loading commit data...
robots.txt Loading commit data...