mirror of
https://github.com/golang/go.git
synced 2025-10-19 11:03:18 +00:00
83df0afc4e
This change adds the flight recorder to the trace package. Flight recording is a technique in which trace data is kept in a circular buffer and can be flushed upon request. The implementation will be added in follow-up CLs. The flight recorder has already been implemented inside of the golang.org/x/exp/trace package. This copies the current implementation and modifies it to work within the runtime/trace package. The changes include: This adds the ability for multiple consumers (both the execution tracer and the flight recorder) to subscribe to tracing events. This change allows us to add multiple consumers without making major modifications to the runtime. Future optimizations are planned for this functionality. This removes the use of byte readers from the process that parses and processes the trace batches. This modifies the flight recorder to not parse out the trace clock frequency, since that requires knowledge of the format that's unfortunate to encode in yet another place. Right now, the trace clock frequency is considered stable for the lifetime of the program, so just grab it directly from the runtime. This change adds an in-band end-of-generation signal to the internal implementation of runtime.ReadTrace. The internal implementation is exported via linkname to runtime/trace, so the flight recorder can identify exactly when a generation has ended. This signal is also useful for ensuring that subscribers to runtime trace data always see complete generations, by starting or stopping data streaming only at generation boundaries. For #63185 Change-Id: I5c15345981a6bbe9764a3d623448237e983c64ec Reviewed-on: https://go-review.googlesource.com/c/go/+/673116 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> |
||
|---|---|---|
| .. | ||
| next | ||
| except.txt | ||
| go1.1.txt | ||
| go1.2.txt | ||
| go1.3.txt | ||
| go1.4.txt | ||
| go1.5.txt | ||
| go1.6.txt | ||
| go1.7.txt | ||
| go1.8.txt | ||
| go1.9.txt | ||
| go1.10.txt | ||
| go1.11.txt | ||
| go1.12.txt | ||
| go1.13.txt | ||
| go1.14.txt | ||
| go1.15.txt | ||
| go1.16.txt | ||
| go1.17.txt | ||
| go1.18.txt | ||
| go1.19.txt | ||
| go1.20.txt | ||
| go1.21.txt | ||
| go1.22.txt | ||
| go1.23.txt | ||
| go1.24.txt | ||
| go1.txt | ||
| README | ||
Files in this directory are data for Go's API checker ("go tool api", in src/cmd/api).
Each file is a list of API features, one per line.
go1.txt (and similarly named files) are frozen once a version has been
shipped. Each file adds new lines but does not remove any.
except.txt lists features that may disappear without breaking true
compatibility.
Starting with go1.19.txt, each API feature line must end in "#nnnnn"
giving the GitHub issue number of the proposal issue that accepted
the new API. This helps with our end-of-cycle audit of new APIs.
The same requirement applies to next/* (described below), which will
become a go1.XX.txt for XX >= 19.
The next/ directory contains the only files intended to be mutated.
Each file in that directory contains a list of features that may be added
to the next release of Go. The files in this directory only affect the
warning output from the go api tool. Each file should be named
nnnnn.txt, after the issue number for the accepted proposal.
(The #nnnnn suffix must also appear at the end of each line in the file;
that will be preserved when next/*.txt is concatenated into go1.XX.txt.)
When you add a file to the api/next directory, you must add at least one file
under doc/next. See doc/README.md for details.