Adds runtime.debugPinnerV1 which returns a runtime.Pinner object that
pins itself. This is intended to be used by debuggers in conjunction
with runtime.debugCall to keep heap memory reachable even if it isn't
referenced from anywhere else.
Change-Id: I508ee6a7b103e68df83c96f2e04a0599200300dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/558276
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Austin Clements <austin@google.com>
It's broken with the latest XCode versions, and is also already disabled
on darwin builders. Disable the test to get go test cmd/go working on
local builds again.
For #64947
Change-Id: I5a4b46cf23cbe887df4903f90b54cd2225f51233
Reviewed-on: https://go-review.googlesource.com/c/go/+/584937
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The gotoolchain_issue66175 script test would fail if a binary named
go1.21 or go1.22 was present in the system PATH. Clear the path at the
beginning of the test to make it independent of the system path.
Fixes#67277
Change-Id: I6d9133aee5b20ab116e07b659e8ecf3eb8add4ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/584258
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: Iaaf2e9dbcffb4b1944817b0a4aaecd3554ebfec1
GitHub-Last-Rev: f4ec85a05e
GitHub-Pull-Request: golang/go#67280
Reviewed-on: https://go-review.googlesource.com/c/go/+/584695
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently in a lot of packages we define functions for appending/decoding
mostly BigEndian data (see internal/chacha8rand, net/netip,
internal/boring/sha, hash/crc64, and probably more), because we don't
want to depend on encoding/binary, because of #54097.
This change introduces a new package internal/byteorder, that
will allow us to remove all of the functions and replace them with
internal/byteorder.
Updates #54097
Change-Id: I03e5ea1eb721dd98bdabdb25786f889cc5de54c5
GitHub-Last-Rev: 3f07d3dfb4
GitHub-Pull-Request: golang/go#67183
Reviewed-on: https://go-review.googlesource.com/c/go/+/583298
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Chunk returns an iterator over consecutive sub-slices of up to n elements of s.
Fixes#53987.
Change-Id: I508274eca388db39550eb9e4d8abd5ce68d29d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/562935
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Go API is defined through exported symbols. When a package is
imported, the compiler ensures that only exported symbols can be
accessed, and the go command ensures that internal packages cannot
be imported. This ensures API integrity. But there is a hole:
using linkname, one can access internal or non-exported symbols.
Linkname is a mechanism to give access of a symbol to a package
without adding it to the public API. It is intended for coupled
packages to share some implementation details, or to break
circular dependencies, and both "push" (definition) and "pull"
(reference) sides are controlled, so they can be updated in sync.
Nevertheless, it is abused as a mechanism to reach into internal
details of other packages uncontrolled by the user, notably the
runtime. As the other package evolves, the code often breaks,
because the linknamed symbol may no longer exist, or change its
signature or semantics.
This CL adds a mechanism to enforce the integrity of linknames.
Generally, "push" linkname is allowed, as the package defining
the symbol explicitly opt in for access outside of the package.
"Pull" linkname is checked and only allowed in some circumstances.
Given that there are existing code that use "pull"-only linkname
to access other package's internals, disallowing it completely is
too much a change at this point in the release cycle. For a start,
implement a hard-coded blocklist, which contains some newly added
internal functions that, if used inappropriately, may break memory
safety or runtime integrity. All blocked symbols are newly added
in Go 1.23. So existing code that builds with Go 1.22 will
continue to build.
For the implementation, when compiling a package, we mark
linknamed symbols in the current package with an attribute. At
link time, marked linknamed symbols are checked against the
blocklist. Care is taken so it distinguishes a linkname reference
in the current package vs. a reference of a linkname from another
package and propagated to the current package (e.g. through
inlining or instantiation).
Symbol references in assembly code are similar to linknames, and
are treated similarly.
Change-Id: I8067efe29c122740cd4f1effd2dec2d839147d5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/584598
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Running with few threads usually does not need 500ms to crash, so let it
crash as soon as possible. While the test may caused more time on slow
machine, try to expand the sleep time in test.
Updates #64752
Change-Id: I635fab846bd5e1735808d4d47bb9032d5a04cc2b
GitHub-Last-Rev: 84f3844ac0
GitHub-Pull-Request: golang/go#65018
Reviewed-on: https://go-review.googlesource.com/c/go/+/554615
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
See CL 557596, according to the go specification,
the iterated variable type should
be the same as the iterated integer type.
For #66056
Change-Id: I96c87440328c2c50c40d76ecf2f222a331be1ce9
GitHub-Last-Rev: 8f80e401e5
GitHub-Pull-Request: golang/go#67269
Reviewed-on: https://go-review.googlesource.com/c/go/+/584516
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This patch fixes a problem with how the .dynamic and .got sections are
handled during PIE linking on ELF targets. These sections were being
given addresses that overlapped with the .data.rel.ro section, which
resulted in binaries that worked correctly but confused the binutils
"strip" tool (which, confusingly, produced non-working stripped output
when used on Go PIE binaries without returning a non-zero exit
status). The new RELRO PIE code path preserves .dynamic and .got as
their own independent sections, while ensuring that they make it into
the RELRO segment. A new test verifies that we can successfully strip
and run Go PIE binaries, and also that we don't wind up with any
sections whose address ranges overlap.
Fixes#67261.
Updates #45681.
Change-Id: If874be05285252a9b074d4a1fc6a4023b9a28b5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/584595
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I8c5c0831b94261c5880ca22b7ea52cce034d88f1
GitHub-Last-Rev: 5fd119d4e8
GitHub-Pull-Request: golang/go#67248
Reviewed-on: https://go-review.googlesource.com/c/go/+/583876
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
They are editor backup files. They are ignored by .gitignore,
so they can never be real files in the Go repo.
Change-Id: I58800e6e9f939e0bd21b086243b9260bcc8cd770
Reviewed-on: https://go-review.googlesource.com/c/go/+/584675
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Change-Id: Ic88ef6b60b5a772865603971411fd5d37ef45006
Reviewed-on: https://go-review.googlesource.com/c/go/+/584656
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
CL 583755 removed all uses of the ifaceIndir function,
and the function itself. Unfortunately, ifaceIndir is accessed
using go:linkname by the popular github.com/goccy/go-json package.
A bug has been filed to fix this upstream:
https://github.com/goccy/go-json/issues/506
Until that bug is fixed and the fix is distributed,
keep this function available.
With luck we can remove this in the 1.24 release.
For #67279
Change-Id: I15fccf82d7a172a0b15cdbefb0a0a48381998938
Reviewed-on: https://go-review.googlesource.com/c/go/+/584676
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
A DNS name prefixed with an empty label should be considered invalid
when checking constraints (i.e. ".example.com" does not satisfy a
constraint of "example.com").
Updates #65085
Change-Id: I42919dc06abedc0e242ff36b2a42b583b14857b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/561615
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For #66056
Change-Id: Ib47c07b2527d8213584b72e2575a353f2deaed68
GitHub-Last-Rev: 525a5c3fa4
GitHub-Pull-Request: golang/go#67268
Reviewed-on: https://go-review.googlesource.com/c/go/+/584515
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Temporarily mark the function runtime.throw as "go:noinline" for the
time being to work around problems introduced by CL 581215. We do not
ordinarily inline runtime.throw unless the build is beind done with an
elevated inline budget (e.g. "-gcflags=-l=4"), so this change should
only have an effect for those special builds.
Updates #67274.
Change-Id: I3811913b8d441e0ddb1d4c7d7297ef23555582a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/584616
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
To pull in CL 583836
Commands run
go get golang.org/x/mod@6686f416970d4b8e2f54f521955dee89e6763c4b
go mod tidy
go mod vendor
For #67238
For #66625
Change-Id: I77e49706481e068d27072a38d0d2464aa40d2dd0
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/584335
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#61899
Change-Id: Icbde1ac8293723eefc3251008ae9711e756ed1b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/568477
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#67175
Defines a MachoPlatorm constant in OS_Darwin for MacCatalyst build. This enables adding the suffix $INODE64 on syscall methods needed for amd64 Darwin platform.
Change-Id: Ie677e241599e2a14359c5809fa9ddb3b63161629
GitHub-Last-Rev: feae982e68
GitHub-Pull-Request: golang/go#67176
Reviewed-on: https://go-review.googlesource.com/c/go/+/583295
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
This is a reapply of CL 544019 and CL 569815, but with
less aggressive semantics as discussed in proposal #66343.
Error deletes Content-Encoding, since it is writing the response
and any preset encoding may not be correct.
On the error-serving path in ServeContent/ServeFile/ServeFS,
these functions delete additional headers: Etag, Last-Modified,
and Cache-Control. The caller may have set these intending
them for the success response, and they may well not be correct
for error responses.
Fixes#50905.
Fixes#66343.
Change-Id: I873d33edde1805990ca16d85ea8d7735b7448626
Reviewed-on: https://go-review.googlesource.com/c/go/+/571995
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add counters for invocations and provided flag names.
For #58894
Change-Id: Ibd4eeca905d277879b601d95bab524fbced6a98b
Reviewed-on: https://go-review.googlesource.com/c/go/+/584276
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add cmd/internal/telemetry to cmd/dist's bootstrapDirs so it's built
when bootstrapping the compiler. cmd/internal/telemetry is a wrapper
arount telemetry functions that stubs out the functions when built in
bootstrap mode to avoid dependencies on x/telemetry in bootstrap mode.
Call telemetry.Start with an empty config to open the counter file, and
increment a counter for when the command is invoked.
After flags are parsed, increment a counter for each of the names of the
flags that were passed in. The counter names will be compile/flag:<name>
so for example we'll have compile/flag:e and compile/flag:E.
In FatalfAt, increment a stack counter for internal errors.
For #58894
Change-Id: Ia5a8a63aa43b2276641181626cbfbea7e4647faa
Reviewed-on: https://go-review.googlesource.com/c/go/+/570679
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The compiler was accidentally using internal/godebug from
the Go 1.20 bootstrap toolchain and didn't get the behavior
it expected. Generalizing, we should never assume we know
the behavior of an internal package from an earlier bootstrap
toolchain, so disallow that case in cmd/dist.
Change-Id: I41e079f6120f4081124619bbe2b30069c96b9f29
Reviewed-on: https://go-review.googlesource.com/c/go/+/581496
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
The main reason not to use internal/godebug is that
people often set GODEBUGs to change the behavior
of the programs they are running with 'go run' or 'go test'.
We don't want the compiler to behave differently as well
in that case: that's too many changes.
Using internal/godebug also breaks bootstrapping
with toolchains that don't have it, or future toolchains
that have a different API in that package.
Change-Id: Ib5a8a74e2451649d8838b71f274b4e3a78939dfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/581495
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#66056
Change-Id: I1e24636e43e68cd57576c39b014e0826fb6c322c
GitHub-Last-Rev: 319ad8ea7c
GitHub-Pull-Request: golang/go#66824
Reviewed-on: https://go-review.googlesource.com/c/go/+/578815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Using port 9 is weird and at least once triggered a suspicious
activity alert.
Fixes#67264
Change-Id: If4179f054829c175b9f3a51c3bc2a3ca4afa74b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/584416
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Must be Lock/Unlock to be flagged by vet.
Change-Id: I792ebd68b168621a660b9595b5d06a465d0d7bf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/584355
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL causes the printing of panic values to ensure that all
newlines in the output are immediately followed by a tab, so
that there is no way for a maliciously crafted panic value to
fool a program attempting to parse the traceback into thinking
that the panic value is in fact a goroutine stack.
See https://github.com/golang/go/issues/64590#issuecomment-1932675696
+ release note
Updates #64590
Updates #63455
Change-Id: I5142acb777383c0c122779d984e73879567dc627
Reviewed-on: https://go-review.googlesource.com/c/go/+/581215
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently if the first batch of the next generation in the trace is
broken, then the previous generation will fail to parse. The parser
currently relies on one complete batch of the next generation to
continue.
However, this means that recovering a complete generation from a trace
with a broken tail doesn't always work. Luckily, this is fixable. When
the parser encounters an error reading a batch in a generation, it
simply writes down that error and processes it later, once the
generation has been handled. If it turns out the error was for the same
generation and something bigger is broken, then the parser will catch
that sooner when validating the generation's events and the error will
never show up. Otherwise, the generation will parse through successfully
and we'll emit the error once that's done.
Fixes#55160.
Change-Id: I9c9c19d5bb163c5225e18d11594ca2a8793c6950
Reviewed-on: https://go-review.googlesource.com/c/go/+/584275
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently it's possible for next and yield to be called out of sequence,
which will result in surprising behavior due to the implementation.
Because we blindly coroswitch between goroutines, calling next from the
iterator, or yield from the calling goroutine, will actually switch back
to the other goroutine. In the case of next, we'll switch back with a
stale (or zero) value: the results are basically garbage. In the case of
yield, we're switching back to the *same* goroutine, which will crash in
the runtime.
This change adds a single bool to ensure that next and yield are always
called in sequence. That is, every next must always be paired with a
yield before continuing. This restricts what can be done with Pull, but
prevents observing some truly strange behaviors that the user of Pull
likely did not intend, or can't easily predict.
Change-Id: I6f72461f49c5635d6914bc5b968ad6970cd3c734
Reviewed-on: https://go-review.googlesource.com/c/go/+/583676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently freeSpan is called before large object stats are updated when
sweeping large objects. This means heapStats.inHeap might get subtracted
before the large object is added to the largeFree field. The end result
is that the /memory/classes/heap/unused:bytes metric, which subtracts
live objects (alloc-free) from inHeap may overflow.
Fix this by always updating the large object stats before calling
freeSpan.
Fixes#67019.
Change-Id: Ib02bd8dcd1cf8cd1bc0110b6141e74f678c10445
Reviewed-on: https://go-review.googlesource.com/c/go/+/583380
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The page tracer's functionality is now captured by the regular execution
tracer as an experimental GODEBUG variable. This is a lot more usable
and maintainable than the page tracer, which is likely to have bitrotted
by this point. There's also no tooling available for the page tracer.
Change-Id: I2408394555e01dde75a522e9a489b7e55cf12c8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/583379
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Move profiling pc buffers from being stack allocated to an m field.
This is motivated by the next patch, which will increase the default
stack depth to 128, which might lead to undesirable stack growth for
goroutines that produce profiling events.
Additionally, this change paves the way to make the stack depth
configurable via GODEBUG.
Change-Id: Ifa407f899188e2c7c0a81de92194fdb627cb4b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/574699
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change adds expensive alloc/free events to traces, guarded by a
GODEBUG that can be set at run time by mutating the GODEBUG environment
variable. This supersedes the alloc/free trace deleted in a previous CL.
There are two parts to this CL.
The first part is adding a mechanism for exposing experimental events
through the tracer and trace parser. This boils down to a new
ExperimentalEvent event type in the parser API which simply reveals the
raw event data for the event. Each experimental event can also be
associated with "experimental data" which is associated with a
particular generation. This experimental data is just exposed as a bag
of bytes that supplements the experimental events.
In the runtime, this CL organizes experimental events by experiment.
An experiment is defined by a set of experimental events and a single
special batch type. Batches of this special type are exposed through the
parser's API as the aforementioned "experimental data".
The second part of this CL is defining the AllocFree experiment, which
defines 9 new experimental events covering heap object alloc/frees, span
alloc/frees, and goroutine stack alloc/frees. It also generates special
batches that contain a type table: a mapping of IDs to type information.
Change-Id: I965c00e3dcfdf5570f365ff89d0f70d8aeca219c
Reviewed-on: https://go-review.googlesource.com/c/go/+/583377
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
allocfreetrace prints all allocations and frees to stderr. It's not
terribly useful because it has a really huge overhead, making it not
feasible to use except for the most trivial programs. A follow-up CL
will replace it with something that is both more thorough and also lower
overhead.
Change-Id: I1d668fee8b6aaef5251a5aea3054ec2444d75eb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/583376
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
When we optimize append(s, make([]T, n)...), we have to be careful
not to pass &s[0] + len(s)*sizeof(T) as the argument to memclr, as that
pointer might be past-the-end. This can only happen if n is zero, so
just special-case n==0 in the generated code.
Fixes#67255
Change-Id: Ic680711bb8c38440eba5e759363ef65f5945658b
Reviewed-on: https://go-review.googlesource.com/c/go/+/584116
Reviewed-by: Austin Clements <austin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Rename the subcommand flag counter names from
go/flag/<subcommand>/<flagname> to go/<subcommand>/flag/<flagname>.
Also remove the special case that adds counters for buildmode flag
values and instead add an additional counter for the flag values.
The new counter has the form go/<subcommand>/flag/buildmode:<flagvalue>.
We use a new CountFlagValue function that's been added to the
internal/telemetry package to help with this.
Finally add the go/invocations counter
Change-Id: I995b6b0009ba0f58faeb3e2a75f3b137e4136209
Reviewed-on: https://go-review.googlesource.com/c/go/+/583917
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Commands run (in both src/ and src/cmd/)
go get golang.org/x/telemetry@2790727
go mod tidy
go mod vendor
Change-Id: Idbabcc4a3069afac08d2735fac264577846ea1d7
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/584236
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This is a requirement of golang.org/x/telemetry@2790727 but the diff is
so big it's being vendored in a separate CL.
Commands run:
go get golang.org/x/sys@v0.20.0
go mod tidy
go mod vendor
Change-Id: Idbeef95dab71449f67d21552636137e08db0f54d
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/584235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When GODEBUG=gotypesalias=1 is set, use an actual Alias type to
represent any, rather than a legacy alias representation. This makes any
consistent with other interface aliases, and will eventually make
obsolete the various workarounds for formatting any as 'any' rather than
'interface{}'.
Since any is a global in the Universe scope, we must hijack Scope.Lookup
to select the correct representation. Of course, this also means that we
can't support type checking concurrently while mutating gotypesalias
(or, in the case of types2, Config.EnableAlias). Some care is taken to
ensure that the type checker panics in the event of this type of misuse.
For now, we must still support the legacy representation of any, and the
existing workarounds that look for a distinguished any pointer. This is
done by ensuring that both representations have the same underlying
pointer, and by updating workarounds to consider Underlying.
Fixesgolang/go#66921
Change-Id: I81db7e8e15317b7a6ed3b406545db15a2fc42f57
Reviewed-on: https://go-review.googlesource.com/c/go/+/580355
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Tweak the new telemetry proposal template added in CL 583496:
- Shorten the description, as it is formatted on one conspicuously long
line in the template picker.
- Use folded style for label descriptions, as their line breaks cause
the resulting paragraph to flow awkwardly.
Change-Id: I3089ac0717646e153765548d4bebd8d4751933b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/583916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
