Change-Id: I7507e6cff00d027fd7840e0661499efc63353f6e
GitHub-Last-Rev: 81348ed39d
GitHub-Pull-Request: golang/go#66820
Reviewed-on: https://go-review.googlesource.com/c/go/+/578441
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also simulate TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT with
TCP_KEEPALIVE_THRESHOLD + TCP_KEEPALIVE_ABORT_THRESHOLD for
Solaris prior to 11.4
Fixes#9614Fixes#64251
Change-Id: Ia0777076a7952630bc52761cddd0b06b0d81c6a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/577195
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: I3eb41562bf6478b288d9f41915fd7d027399a6ba
GitHub-Last-Rev: 218b9cb067
GitHub-Pull-Request: golang/go#66551
Reviewed-on: https://go-review.googlesource.com/c/go/+/574575
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#63116
Change-Id: Iab8c415555ab85097be6d2d133b3349c5219a23b
GitHub-Last-Rev: 8a8177b9af
GitHub-Pull-Request: golang/go#63348
Reviewed-on: https://go-review.googlesource.com/c/go/+/532217
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Along with the removal of the slow path from Linux and *BSD.
For #59359
Change-Id: I6c79594252e5e5f1c1c57c11e09458fcae3793d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/577175
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Fixes#65812
Change-Id: I63facb32eeddbe9b6e0279f1c039779ba2e2ab7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/575015
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Commit-Queue: 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>
Fixes#66760
Change-Id: I6ba5bc5b00506b66cb8dc3984a61f32a6358d9bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/577895
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is a practical use of CL 577915, follow-up to CL 577835.
Change-Id: Ibe7e2fa11b444afa1898dc6f6aba1512fe98f1fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/578195
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
It wasn't DocLink compatible in a number of ways.
Change-Id: Ib7ab9a908ef47561ac70cdc0c157d49dcfd03a02
Reviewed-on: https://go-review.googlesource.com/c/go/+/577375
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fixes#66784
Change-Id: Ifd17e0830e04e7028d8a876c6c12c496f5167887
Reviewed-on: https://go-review.googlesource.com/c/go/+/578395
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I449fcb008fa4c1f51de0bef9f016907d8b99da67
GitHub-Last-Rev: b2e84f1a8a
GitHub-Pull-Request: golang/go#66772
Reviewed-on: https://go-review.googlesource.com/c/go/+/578135
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In both the v1 and v2 cmd/trace, pprofMatchingGoroutines will generate
no output at all if the filter name passed to it is the empty string.
This is rather pointless because there are at least two places where we
don't pass a name to filter. Modify pprofMatchingGoroutines to include
*all* goroutines in the trace if the name to filter by is not specified.
For #66782.
Change-Id: I6b72298d676bc93892b075a7426e6e56bc6656c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/578356
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>
Turns out we ported all the profile generation, but forgot to actually
support the command line flags for them! This change fixes the issue by
handling the different kinds of profiles and writing them out to stdout.
Fixes#66782.
Change-Id: I7756fb4636ce8daaf11ed471be79c86ce3d463cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/578318
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This will avoid a potential endless loop for a corrupt DNS packet.
For #66754
Change-Id: I46591b3f7695bcc88d2312833e45955f8c129d2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/578375
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently TestGCStress' main loop allocates a randomly-sized byte slice
in a loop. On the windows-386 builder, it looks like the following is
happening.
In such heavily-allocating scenarios, the test seems to be able to
outrun the GC. This is a known issue on all platforms, but it looks to
me like there may be a real issue with mark termination. (Fixing that is
outside the scope of this change, but relevant here.)
Furthermore, while the test is ramping up, the pacer is taking time to
acclimate to the high allocation rate. This is probably made worse due
to the coarse time granularity on Windows, since the pacer relies on
accurate time measurements.
Because the pacer is ramping up, it isn't starting early enough, causing
a lot of memory to get allocated black and inflate the live heap size.
This happens for more than one cycle.
Last but not least, because the core allocating loop of this test
allocates randomly-sized byte slices, we could just get unlucky and
inflate the live heap by much more sometimes. Furthermore, the
randomness creates chaos for the pacer that is totally unnecessary for
this test.
Although I couldn't reproduce the issue we're seeing on the trybots in a
gomote, I *could* reproduce memory spikes in general. These memory
spikes always occurred before the pacer had a chance to "warm up," in
the first two cycles after the heavy allocating begins.
I believe the flakiness we're seeing is all of these factors lining up,
because if I just make the size of the allocated byte slices smaller and
non-random, I can no longer reproduce the memory spikes. This change
implements this as a fix in the hope that it'll resolve the flakiness.
Fixes#66624.
Change-Id: I478d45e7c600e5aee4b21dbe831e1f287284f5e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/578319
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There is no hyphen between the organization and the number.
For example, https://standards.ieee.org/ieee/754/6210/
shows the string "IEEE 754-2019" and not "IEEE-754-2019".
This assists in searching for "IEEE 754" in documentation
and not missing those using "IEEE-754".
Change-Id: I9a50ede807984ff1e2f17390bc1039f6a5d162e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/575438
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
For Go 1.23, we decided to no longer support the old CLI interface
exposed by wasmtime. This removes the extra logic included to support
both the new and the old CLI interface. Now only versions of wasmtime
14 and newer are supported.
Fixes#63718
Change-Id: Iea31388dc41bc8d73caa923c7e4acae2228bf515
Reviewed-on: https://go-review.googlesource.com/c/go/+/577135
Reviewed-by: Randy Reddig <randy.reddig@fastly.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Use "slices.Equal" instead of "reflect.DeepEqual".
Replace unnecessary helper type "byIndex" with "slices.SortFunc".
No effect on benchmarks.
Change-Id: I1fb2768ea6d9db7f487408fa109343be3f1741d5
GitHub-Last-Rev: 8429bc1452
GitHub-Pull-Request: golang/go#66646
Reviewed-on: https://go-review.googlesource.com/c/go/+/575715
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Like on other BSDs, use faccessat(AT_FDCWD, path, mode, AT_EACCESS)
Change-Id: I80f8d327dd152576165b9206e32dfb749b41d187
Reviewed-on: https://go-review.googlesource.com/c/go/+/538836
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
CL 570555 replaced a loop which added empty
color.RGBA elements with a call to clear.
color.Palette is a slice of interfaces, so using
clear results in a slice of nil elements, rather
than what we previously had which was empty
color.RGBA elements. This could cause a panic when
attempting to re-encode a GIF which had an
extended color palette because of the weird
transparency hack.
This was discovered by OSS-Fuzz. I've added a test
case using their reproducer in order to prevent
future regressions.
Change-Id: I00a89257d90b6cca68672173eecdaa0a24f18d9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/577555
Reviewed-by: Nigel Tao <nigeltao@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For #61060
Change-Id: I13cd73b4062cb7bd248d2a4afae06dfa29ac0203
Reviewed-on: https://go-review.googlesource.com/c/go/+/577955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Depending on the query, a RawBytes can contain memory owned by the
driver or by database/sql:
If the driver provides the column as a []byte,
RawBytes aliases that []byte.
If the driver provides the column as any other type,
RawBytes contains memory allocated by database/sql.
Prior to this CL, Rows.Scan will reuse existing capacity in a
RawBytes to permit a single allocation to be reused across rows.
When a RawBytes is reused across queries, this can result
in database/sql writing to driver-owned memory.
Add a buffer to Rows to store RawBytes data, and reuse this
buffer across calls to Rows.Scan.
Fixes#65201
Change-Id: Iac640174c7afa97eeb39496f47dec202501b2483
Reviewed-on: https://go-review.googlesource.com/c/go/+/557917
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Document that links to symbols in the standard library can be
written as "[foo]", without the actual link.
For #64169.
Change-Id: I9d8a33e85df70037320a169d55a2bb4a8a981ebf
Reviewed-on: https://go-review.googlesource.com/c/go/+/577915
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This test has been OOMing on 32-bit platforms for a bit. I suspect the
very high allocation rate is causing the program to outrun the GC in
some corner-case scenarios, especially on 32-bit Windows.
I don't have a strong grasp of what's going on yet, but lowering the
memory footprint should help with the flakiness. This shouldn't
represent a loss in test coverage, since we're still allocating and
assisting plenty (tracing the latter is a strong reason this test
exists).
For #66624.
Change-Id: Idd832cfc5cde04701386919df4490f201c71130a
Reviewed-on: https://go-review.googlesource.com/c/go/+/577475
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>
The existing implementation of traceMap is a hash map with a fixed
bucket table size which scales poorly with the number of elements added
to the map. After a few thousands elements are in the map, it tends to
fall over.
Furthermore, cleaning up the trace map is currently non-preemptible,
without very good reason.
This change replaces the traceMap implementation with a simple
append-only concurrent hash-trie. The data structure is incredibly
simple and does not suffer at all from the same scaling issues.
Because the traceMap no longer has a lock, and the traceRegionAlloc it
embeds is not thread-safe, we have to push that lock down. While we're
here, this change also makes the fast path for the traceRegionAlloc
lock-free. This may not be inherently faster due to contention on the
atomic add, but it creates an easy path to sharding the main allocation
buffer to reduce contention in the future. (We might want to also
consider a fully thread-local allocator that covers both string and
stack tables. The only reason a thread-local allocator isn't feasible
right now is because each of these has their own region, but we could
certainly group all them together.)
Change-Id: I8c06d42825c326061a1b8569e322afc4bc2a513a
Reviewed-on: https://go-review.googlesource.com/c/go/+/570035
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently lots of functions require systemstack because the trace buffer
might get flushed, but that will already switch to the systemstack for
the most critical bits (grabbing trace.lock). That means a lot of this
code is non-preemptible when it doesn't need to be. We've seen this
cause problems at scale, when dumping very large numbers of stacks at
once, for example.
This is a re-land of CL 572095 which was reverted in CL 577376. This
re-land includes a fix of the test that broke on the longtest builders.
Change-Id: Ia8d7cbe3aaa8398cf4a1818bac66c3415a399348
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/577377
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Change-Id: I28baf375502ccf3b0dfcc8250650e914ac7bae78
Reviewed-on: https://go-review.googlesource.com/c/go/+/577835
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Jes Cok <xigua67damn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This is covered by the existing tests under gotypesalias=1.
Change-Id: Ia17f35fe580b745fa4bdaf4689dfe9c2ed6ebc5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/577735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
This change reenables the legacy three-phase resolution
(non-alias typenames, aliases, the rest) even when
GODEBUG=gotypesalias=1. Unfortunately the existing test case
for #50259 causes the simpler logic to fail.
Updates #50259
Updates #65294
Change-Id: Ibfaf8146e46760718673a916a9b220a9d678409a
Reviewed-on: https://go-review.googlesource.com/c/go/+/577616
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Flag flip to enable stack slot merging by default when optimizing.
Please see the earlier CL for details on what this is doing.
Updates #62737.
Updates #65532.
Updates #65495.
Change-Id: I8e30d553e74ace43d418f883199721f05320d3d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/576681
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
It is possible to have situations where a given ir.Name is
non-address-taken at the source level, but whose address is
materialized in order to accommodate the needs of arch-dependent
memory ops. The issue here is that the SymAddr op will show up as
touching a variable of interest, but the subsequent memory op will
not. This is generally not an issue for computing whether something is
live across a call, but it is problematic for collecting the more
fine-grained live interval info that drives stack slot merging.
As an example, consider this Go code:
package p
type T struct {
x [10]int
f float64
}
func ABC(i, j int) int {
var t T
t.x[i&3] = j
return t.x[j&3]
}
On amd64 the code sequences we'll see for accesses to "t" might look like
v10 = VarDef <mem> {t} v1
v5 = MOVOstoreconst <mem> {t} [val=0,off=0] v2 v10
v23 = LEAQ <*T> {t} [8] v2 : DI
v12 = DUFFZERO <mem> [80] v23 v5
v14 = ANDQconst <int> [3] v7 : AX
v19 = MOVQstoreidx8 <mem> {t} v2 v14 v8 v12
v22 = ANDQconst <int> [3] v8 : BX
v24 = MOVQloadidx8 <int> {t} v2 v22 v19 : AX
v25 = MakeResult <int,mem> v24 v19 : <>
Note that the the loads and stores (ex: v19, v24) all refer directly
to "t", which means that regular live analysis will work fine for
identifying variable lifetimes. The DUFFZERO is (in effect) an
indirect write, but since there are accesses immediately after it we
wind up with the same live intervals.
Now the same code with GOARCH=ppc64:
v10 = VarDef <mem> {t} v1
v20 = MOVDaddr <*T> {t} v2 : R20
v12 = LoweredZero <mem> [88] v20 v10
v3 = CLRLSLDI <int> [212543] v7 : R5
v15 = MOVDaddr <*T> {t} v2 : R6
v19 = MOVDstoreidx <mem> v15 v3 v8 v12
v29 = CLRLSLDI <int> [212543] v8 : R4
v24 = MOVDloadidx <int> v15 v29 v19 : R3
v25 = MakeResult <int,mem> v24 v19 : <>
Here instead of memory ops that refer directly to the symbol, we take
the address of "t" (ex: v15) and then pass the address to memory ops
(where the ops themselves no longer refer to the symbol).
This patch enhances the stack slot merging liveness analysis to handle
cases like the PPC64 one above. We add a new phase in candidate
selection that collects more precise use information for merge
candidates, and screens out candidates that are too difficult to
analyze. The phase make a forward pass over each basic block looking
for instructions of the form vK := SymAddr(N) where N is a raw
candidate. It then creates an entry in a map with key vK and value
holding name and the vK use count. As the walk continues, we check for
uses of of vK: when we see one, record it in a side table as an
upwards exposed use of N. At each vK use we also decrement the use
count in the map entry, and if we hit zero, remove the map entry. If
we hit the end of the basic block and we still have map entries, this
implies that the address in question "escapes" the block -- at that
point to be conservative we just evict the name in question from the
candidate set.
Although this CL fixes the issues that forced a revert of the original
merging CL, this CL doesn't enable stack slot merging by default; a
subsequent CL will do that.
Updates #62737.
Updates #65532.
Updates #65495.
Change-Id: Id41d359a677767a8e7ac1e962ae23f7becb4031f
Reviewed-on: https://go-review.googlesource.com/c/go/+/576735
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For -gcflags=-d=mergelocalstrace=1 (which reports estimated savings
from stack slot merging), emit separate values for pointerful vs
non-pointerful variables, for a bit more detail.
Updates #62737.
Updates #65532.
Updates #65495.
Change-Id: I9dd27d2a254036448c85c13d189d1ed36157c9d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/576680
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
[This is a partial roll-forward of CL 553055, the main change here
is that the stack slot overlap operation is flagged off by default
(can be enabled by hand with -gcflags=-d=mergelocals=1) ]
Preliminary compiler support for merging/overlapping stack slots of
local variables whose access patterns are disjoint.
This patch includes changes in AllocFrame to do the actual
merging/overlapping based on information returned from a new
liveness.MergeLocals helper. The MergeLocals helper identifies
candidates by looking for sets of AUTO variables that either A) have
the same size and GC shape (if types contain pointers), or B) have the
same size (but potentially different types as long as those types have
no pointers). Variables must be greater than (3*types.PtrSize) in size
to be considered for merging.
After forming candidates, MergeLocals collects variables into "can be
overlapped" equivalence classes or partitions; this process is driven
by an additional liveness analysis pass. Ideally it would be nice to
move the existing stackmap liveness pass up before AllocFrame
and "widen" it to include merge candidates so that we can do just a
single liveness as opposed to two passes, however this may be difficult
given that the merge-locals liveness has to take into account
writes corresponding to dead stores.
This patch also required a change to the way ssa.OpVarDef pseudo-ops
are generated; prior to this point they would only be created for
variables whose type included pointers; if stack slot merging is
enabled then the ssagen code creates OpVarDef ops for all auto vars
that are merge candidates.
Note that some temporaries created late in the compilation process
(e.g. during ssa backend) are difficult to reason about, especially in
cases where we take the address of a temp and pass it to the runtime.
For the time being we mark most of the vars created post-ssagen as
"not a merge candidate".
Stack slot merging for locals/autos is enabled by default if "-N" is
not in effect, and can be disabled via "-gcflags=-d=mergelocals=0".
Fixmes/todos/restrictions:
- try lowering size restrictions
- re-evaluate the various skips that happen in SSA-created autotmps
Updates #62737.
Updates #65532.
Updates #65495.
Change-Id: Ifda26bc48cde5667de245c8a9671b3f0a30bb45d
Reviewed-on: https://go-review.googlesource.com/c/go/+/575415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change makes it possible for the runtime to preempt the zeroing of
large objects that contain pointers. It turns out this is fairly
straightforward with allocation headers, since we can just temporarily
tell the GC that there's nothing to scan for a large object with a
single pointer write (as opposed to trying to zero a whole bunch of
bits, as we would've had to do once upon a time).
Fixes#31222.
Change-Id: I10d0dcfa3938c383282a3eb485a6f00070d07bd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/577495
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change removes the allocheaders, deleting all the old code and
merging mbitmap_allocheaders.go back into mbitmap.go.
This change also deletes the SetType benchmarks which were already
broken in the new GOEXPERIMENT (it's harder to set up than before). We
weren't really watching these benchmarks at all, and they don't provide
additional test coverage.
Change-Id: I135497201c3259087c5cd3722ed3fbe24791d25d
Reviewed-on: https://go-review.googlesource.com/c/go/+/567200
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
The previous CL, CL 570257, made it so that STW time no longer
overlapped with other CPU time tracking. However, what we lost was
insight into the CPU time spent _stopping_ the world, which can be just
as important. There's pretty much no easy way to measure this
indirectly, so this CL implements a direct measurement: whenever a P
enters _Pgcstop, it writes down what time it did so. stopTheWorld then
accumulates all the time deltas between when it finished stopping the
world and each P's stop time into a total additional pause time. The GC
pause cases then accumulate this number into the metrics.
This should cause minimal additional overhead in stopping the world. GC
STWs already take on the order of 10s to 100s of microseconds. Even for
100 Ps, the extra `nanotime` call per P is only 1500ns of additional CPU
time. This is likely to be much less in actual pause latency, since it
all happens concurrently.
Change-Id: Icf190ffea469cd35ebaf0b2587bf6358648c8554
Reviewed-on: https://go-review.googlesource.com/c/go/+/574215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently the GC CPU pause time metrics start measuring before the STW
is complete. This results in a slightly less accurate measurement and
creates some overlap with other timings (for example, the idle time of
idle Ps) that will cause double-counting.
This CL adds a field to worldStop to track the point at which the world
actually stopped and uses that as the basis for the GC CPU pause time
metrics, basically eliminating this overlap.
Note that this will cause Ps in _Pgcstop before the world is fully
stopped to be counted as user time. A follow-up CL will fix this
discrepancy.
Change-Id: I287731f08415ffd97d327f582ddf7e5d2248a6f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/570258
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
This change fixes a possible race with updating metrics and reading
them. The update is intended to be protected by the world being stopped,
but here, it clearly isn't.
Fixing this lets us lower the thresholds in the metrics tests by an
order of magnitude, because the only thing we have to worry about now is
floating point error (the tests were previously written assuming the
floating point error was much higher than it actually was; that turns
out not to be the case, and this bug was the problem instead). However,
this still isn't that tight of a bound; we still want to catch any and
all problems of exactness. For this purpose, this CL adds a test to
check the source-of-truth (in uint64 nanoseconds) that ensures the
totals exactly match.
This means we unfortunately have to take another time measurement, but
for now let's prioritize correctness. A few additional nanoseconds of
STW time won't be terribly noticable.
Fixes#66212.
Change-Id: Id02c66e8a43c13b1f70e9b268b8a84cc72293bfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/570257
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Pull in CL 576895:
ec05fdcd http2: don't retry the first request on a connection on GOAWAY error
For #66668.
Fixes#60636.
Change-Id: I9903607e3d432a5db0325da82eb7f4b378fbddde
Reviewed-on: https://go-review.googlesource.com/c/go/+/576976
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Rather than requiring that HTTP/1 and HTTP/2 servers behave identically
when a misbehaving handler writes too many bytes, check only that both
behave reasonably.
In particular, allow the handler to defer detection of a write overrun
until flush time, and permit the HTTP/2 handler to reset the stream
rather than requring it to return a truncated body as HTTP/1 must.
For #56019
Change-Id: I0838e550c4fc202dcbb8bf39ce0fa4a367ca7e71
Reviewed-on: https://go-review.googlesource.com/c/go/+/577415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
This was missed in CL 571055.
Change-Id: I58d6469c9ea323943e9c230a54fba8f7ec705d47
Reviewed-on: https://go-review.googlesource.com/c/go/+/573515
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently we use stwprocs as the multiplier for the STW CPU time
computation, but this isn't the same as GOMAXPROCS, which is used for
the total time in the CPU metrics. The two numbers need to be
comparable, so this change switches to using maxprocs to make it so.
Change-Id: I423e3c441d05b1bd656353368cb323289661e302
Reviewed-on: https://go-review.googlesource.com/c/go/+/570256
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently this is done manually in two places. Replace these manual
updates with a method that also forces the caller to be mindful that the
number will be multiplied (and that it needs to be). This will make
follow-up changes simpler too.
Change-Id: I81ea844b47a40ff3470d23214b4b2fb5b71a4abe
Reviewed-on: https://go-review.googlesource.com/c/go/+/570255
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I940c63c3040035e507428798d50060cfd0d04e16
GitHub-Last-Rev: e27484cd43
GitHub-Pull-Request: golang/go#66706
Reviewed-on: https://go-review.googlesource.com/c/go/+/577055
Reviewed-by: Than McIntosh <thanm@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>
Auto-Submit: Than McIntosh <thanm@google.com>
Ensure that the immediate for a RORI or RORIW instruction are within range,
adding test coverage. Also use a consistent "immediate out of range" error
for both rotations and shifts.
Change-Id: Id687d7c6e028786f607e9519bbb64dab62b6cf3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/572735
Reviewed-by: M Zhuo <mengzhuo1203@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Pull in CL 576756:
b67a0f05 http2: send correct LastStreamID in stream-caused GOAWAY
It comes with newer x/crypto and x/sys requirements via CL 576516.
For #65051.
Fixes#66668.
Change-Id: Ib6df49b779ff5ea56966ae3de443e87ac7f4ec4f
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/576679
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
