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
Today, it is difficult to trigger specific conditions in the scheduler from a high level Go level. This is because certain behaviors or bugs only manifest via certain multi-threaded race conditions that are difficult or impossible to guarantee. As a result, fixes for bugs in the scheduler often either have strange probabilistic tests that try to entice the scheduler into a specific state (and likely degrade quickly), or they go untested entirely because they are too difficult to reproduce.
Scheduler maintainability could be greatly improved through some kind of testing framework that makes it possible to directly achieve some of these states. There are many forms this could take. e.g., the ability to construct a test scheduler with fake Ms, Ps, and Gs whose states can be explicitly transitioned.
The text was updated successfully, but these errors were encountered:
Currently, gentraceback tracks the closure context of the outermost
frame. This used to be important for "unstarted" calls to reflect
function stubs, where "unstarted" calls are either deferred functions
or the entry-point of a goroutine that hasn't run. Because reflect
function stubs have a dynamic argument map, we have to reach into
their closure context to fetch to map, and how to do this differs
depending on whether the function has started. This was discovered in
However, as part of the register ABI, "go" and "defer" were made much
simpler, and any "go" or "defer" of a function that takes arguments or
returns results gets wrapped in a closure that provides those
arguments (and/or discards the results). Hence, we'll see that closure
instead of a direct call to a reflect stub, and can get its static
argument map without any trouble.
The one case where we may still see an unstarted reflect stub is if
the function takes no arguments and has no results, in which case the
compiler can optimize away the wrapper closure. But in this case we
know the argument map is empty: the compiler can apply this
optimization precisely because the target function has no argument
As a result, we no longer need to track the closure context during
traceback, so this CL drops all of that mechanism.
We still have to be careful about the unstarted case because we can't
reach into the function's locals frame to pull out its context
(because it has no locals frame). We double-check that in this case
we're at the function entry.
I would prefer to do this with some in-code PCDATA annotations of
where to find the dynamic argument map, but that's a lot of mechanism
to introduce for just this. It might make sense to consider this along
Finally, we beef up the test for this so it more reliably forces the
runtime down this path. It's fundamentally probabilistic, but this
tweak makes it better. Scheduler testing hooks (#54475) would make it
possible to write a reliable test for this.
For #54466, but it's a nice clean-up all on its own.
Run-TryBot: Austin Clements <email@example.com>
Reviewed-by: Michael Pratt <firstname.lastname@example.org>
Auto-Submit: Austin Clements <email@example.com>
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Cherry Mui <email@example.com>