delta/go-git.git/src/runtime/trace.go, branch dev.boringcrypto

runtime: move scheduling decisions by schedule into findrunnable

2022-04-26T22:09:34+00:00

This change moves several scheduling decisions made by schedule into
findrunnable. The main motivation behind this change is the fact that
stopped Ms can't become dedicated or fractional GC workers. The main
reason for this is that when a stopped M wakes up, it stays in
findrunnable until it finds work, which means it will never consider GC
work. On that note, it'll also never consider becoming the trace reader,
either.

Another way of looking at it is that this change tries to make
findrunnable aware of more sources of work than it was before. With this
change, any M in findrunnable should be capable of becoming a GC worker,
resolving #44313. While we're here, let's also make more sources of
work, such as the trace reader, visible to handoffp, which should really
be checking all sources of work. With that, we also now correctly handle
the case where StopTrace is called from the last live M that is also
locked (#39004). stoplockedm calls handoffp to start a new M and handle
the work it cannot, and once we include the trace reader in that, we
ensure that the trace reader gets scheduled.

This change attempts to preserve the exact same ordering of work
checking to reduce its impact.

One consequence of this change is that upon entering schedule, some
sources of work won't be checked twice (i.e. the local and global
runqs, and timers) as they do now, which in some sense gives them a
lower priority than they had before.

Fixes #39004.
Fixes #44313.

Change-Id: I5d8b7f63839db8d9a3e47cdda604baac1fe615ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/393880
Reviewed-by: Michael Pratt 
Run-TryBot: Michael Knyszek 
TryBot-Result: Gopher Robot

cmd/compile, runtime: use unwrapped PC for goroutine creation tracing

2022-02-11T20:01:24+00:00

With the switch to the register ABI, we now generate wrapper
functions for go statements in many cases. A new goroutine's start
PC now points to the wrapper function. This does not affect
execution, but the runtime tracer uses the start PC and the
function name as the name/label of that goroutine. If the start
function is a named function, using the name of the wrapper loses
that information. Furthur, the tracer's goroutine view groups
goroutines by start PC. For multiple go statements with the same
callee, they are grouped together. With the wrappers, which is
context-dependent as it is a closure, they are no longer grouped.

This CL fixes the problem by providing the underlying unwrapped
PC for tracing. The compiler emits metadata to link the unwrapped
PC to the wrapper function. And the runtime reads that metadata
and record that unwrapped PC for tracing.

(This doesn't work for shared buildmode. Unfortunate.)

TODO: is there a way to test?

Fixes #50622.

Change-Id: Iaa20e1b544111c0255eb0fc04427aab7a5e3b877
Reviewed-on: https://go-review.googlesource.com/c/go/+/384158
Trust: Cherry Mui 
Reviewed-by: Than McIntosh 
Run-TryBot: Cherry Mui 
TryBot-Result: Gopher Robot

runtime: invalid negative frequency while tracing

2021-12-29T01:44:55+00:00

The riscv64 Hifive Unmatched is the only platform that
failed on testcase TestAnalyzeAnnotations occasionally
after CL 332954 had merged. The failure happens when
ticks per second (freq) is over 1e12 which causing the timestamps
of two events are same.

There are 2 reasons causing big frequency:
1. RDCYCLE is HART based according to the riscv manual which makes
   negative ticks delta
2. negative float64 -> uint64 is undefined and "lucky" negative float
   is too big to handle for trace

For #46737

Change-Id: I1f3c1ac31aae249969000c719c32aaf5a66d29a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373034
Trust: Zhuo Meng 
Run-TryBot: Zhuo Meng 
TryBot-Result: Gopher Robot 
Reviewed-by: Cherry Mui 
Reviewed-by: Michael Knyszek

runtime: ensure at least 1 tick between events

2021-10-19T07:45:46+00:00

ticks might be same after tick division, although the real cputicks
is linear growth

Fixes #46737

Change-Id: I1d98866fbf21b426c6c1c96cc9cf802d7f440f18
Reviewed-on: https://go-review.googlesource.com/c/go/+/330849
Trust: Meng Zhuo 
Trust: Bryan C. Mills 
Run-TryBot: Meng Zhuo 
Reviewed-by: Michael Knyszek 
TryBot-Result: Go Bot

[dev.typeparams] runtime: replace Goarch* constants with internal/goarch versions [generated]

2021-06-17T21:29:09+00:00

[git-generate]
cd src/runtime
gofmt -w -r "sys.Goarch386         -> goarch.Is386" .
gofmt -w -r "sys.GoarchAmd64       -> goarch.IsAmd64" .
gofmt -w -r "sys.GoarchAmd64p32    -> goarch.IsAmd64p32" .
gofmt -w -r "sys.GoarchArm         -> goarch.IsArm" .
gofmt -w -r "sys.GoarchArmbe       -> goarch.IsArmbe" .
gofmt -w -r "sys.GoarchArm64       -> goarch.IsArm64" .
gofmt -w -r "sys.GoarchArm64be     -> goarch.IsArm64be" .
gofmt -w -r "sys.GoarchPpc64       -> goarch.IsPpc64" .
gofmt -w -r "sys.GoarchPpc64le     -> goarch.IsPpc64le" .
gofmt -w -r "sys.GoarchMips        -> goarch.IsMips" .
gofmt -w -r "sys.GoarchMipsle      -> goarch.IsMipsle" .
gofmt -w -r "sys.GoarchMips64      -> goarch.IsMips64" .
gofmt -w -r "sys.GoarchMips64le    -> goarch.IsMips64le" .
gofmt -w -r "sys.GoarchMips64p32   -> goarch.IsMips64p32" .
gofmt -w -r "sys.GoarchMips64p32le -> goarch.IsMips64p32le" .
gofmt -w -r "sys.GoarchPpc         -> goarch.IsPpc" .
gofmt -w -r "sys.GoarchRiscv       -> goarch.IsRiscv" .
gofmt -w -r "sys.GoarchRiscv64     -> goarch.IsRiscv64" .
gofmt -w -r "sys.GoarchS390        -> goarch.IsS390" .
gofmt -w -r "sys.GoarchS390x       -> goarch.IsS390x" .
gofmt -w -r "sys.GoarchSparc       -> goarch.IsSparc" .
gofmt -w -r "sys.GoarchSparc64     -> goarch.IsSparc64" .
gofmt -w -r "sys.GoarchWasm        -> goarch.IsWasm" .
goimports -w *.go

Change-Id: I9d88e1284efabaeb0ee3733cba6286247d078c85
Reviewed-on: https://go-review.googlesource.com/c/go/+/328345
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Matthew Dempsky

[dev.typeparams] runtime: fix import sort order [generated]

2021-06-17T20:42:23+00:00

[git-generate]
cd src/runtime
goimports -w *.go

Change-Id: I1387af0f2fd1a213dc2f4c122e83a8db0fcb15f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/329189
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
Reviewed-by: Matthew Dempsky 
TryBot-Result: Go Bot

[dev.typeparams] runtime: replace uses of runtime/internal/sys.PtrSize with internal/goarch.PtrSize [generated]

2021-06-17T18:54:48+00:00

[git-generate]
cd src/runtime/internal/math
gofmt -w -r "sys.PtrSize -> goarch.PtrSize" .
goimports -w *.go
cd ../..
gofmt -w -r "sys.PtrSize -> goarch.PtrSize" .
goimports -w *.go

Change-Id: I43491cdd54d2e06d4d04152b3d213851b7d6d423
Reviewed-on: https://go-review.googlesource.com/c/go/+/328337
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Matthew Dempsky

runtime: move next_gc and last_next_gc into gcControllerState

2021-04-14T14:03:30+00:00

This change moves next_gc and last_next_gc into gcControllerState under
the names heapGoal and lastHeapGoal respectively. These are
fundamentally GC pacer related values, and so it makes sense for them to
live here.

Partially generated by

rf '
    ex . {
	memstats.next_gc -> gcController.heapGoal
	memstats.last_next_gc -> gcController.lastHeapGoal
    }
'

except for updates to comments and gcControllerState methods, where
they're accessed through the receiver, and trace-related renames of
NextGC -> HeapGoal, while we're here.

For #44167.

Change-Id: I1e871ad78a57b01be8d9f71bd662530c84853bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/306603
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Michael Pratt

runtime: move internal GC statistics from memstats to gcController

2021-04-13T23:42:29+00:00

This change moves certain important but internal-only GC statistics from
memstats into gcController. These statistics are mainly used in pacing
the GC, so it makes sense to keep them in the pacer's state.

This CL was mostly generated via

rf '
    ex . {
	memstats.gc_trigger -> gcController.trigger
	memstats.triggerRatio -> gcController.triggerRatio
	memstats.heap_marked -> gcController.heapMarked
	memstats.heap_live -> gcController.heapLive
	memstats.heap_scan -> gcController.heapScan
    }
'

except for a few special cases, like updating names in comments and when
these fields are used within gcControllerState methods (at which point
they're accessed through the reciever).

For #44167.

Change-Id: I6bd1602585aeeb80818ded24c07d8e6fec992b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/306598
Trust: Michael Knyszek 
Run-TryBot: Michael Knyszek 
TryBot-Result: Go Bot 
Reviewed-by: Michael Pratt

runtime: encapsulate access to allgs

2021-03-05T22:09:52+00:00

Correctly accessing allgs is a bit hairy. Some paths need to lock
allglock, some don't. Those that don't are safest using atomicAllG, but
usage is not consistent.

Rather than doing this ad-hoc, move all access* through forEachG /
forEachGRace, the locking and atomic versions, respectively. This will
make it easier to ensure safe access.

* markroot is the only exception, as it has a far-removed guarantee of
safe access via an atomic load of allglen far before actual use.

Change-Id: Ie1c7a8243e155ae2b4bc3143577380c695680e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/279994
Trust: Michael Pratt 
Run-TryBot: Michael Pratt 
TryBot-Result: Go Bot 
Reviewed-by: Michael Knyszek