symGroupType was needed for dodata. Now that we have converted
dodata to using the loader, stop overwriting it.
Change-Id: Ie94109c0b35dd2f71a19ebb38f8cf20b6a37c624
Reviewed-on: https://go-review.googlesource.com/c/go/+/229994
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In dodata we overwrite symbol types to SDATA. Now we'll stop
doing that, so accept more symbol types here. This is basically
a list of all writeable types handled in dodata that could appear
in XCOFF.
Change-Id: Iee35369162f5acd59806a3f0e6c8d3682620067e
Reviewed-on: https://go-review.googlesource.com/c/go/+/230310
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Originally, we use an assembly function that returns a boolean result to
tell whether the machine has vector facility or not. It is now no longer
needed when we can directly use cpu.S390X.HasVX variable.
Change-Id: Ic1dae851982532bcfd9a9453416c112347f21d87
Reviewed-on: https://go-review.googlesource.com/c/go/+/230318
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Originally, we use an assembly function that returns a boolean result to
tell whether the machine has vector facility or not. It is now no longer
needed when we can directly use cpu.S390X.HasVX variable.
Change-Id: Ic3ffeb9e63238ef41406d97cdc42502145ddb454
Reviewed-on: https://go-review.googlesource.com/c/go/+/230319
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL allows the usage of KDSA instruction when it is available. The
instruction is designed to be resistant to side channel attacks and
offers performance improvement for ed25519.
Benchmarks:
name old time/op new time/op delta
Signing-8 120µs ±20% 62µs ±12% -48.40% (p=0.000 n=10+10)
Verification-8 325µs ±17% 69µs ±10% -78.80% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
Signing-8 448B ± 0% 0B -100.00% (p=0.000 n=10+10)
Verification-8 288B ± 0% 0B -100.00% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
Signing-8 5.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
Verification-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
Change-Id: I0330ce83d807370b419ce638bc2cae4cb3c250dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/202578
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
This reverts CL 33677.
Reason for revert: NetBSD is broken
Updates #38649
Change-Id: Id60e3c97d3cb4fb0053dea03b95dbbb0b850c883
Reviewed-on: https://go-review.googlesource.com/c/go/+/230038
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Several new ones came from my testing (long, repeated runs) and one (assistQueue ->
spine) came from the staticlockranking builder (filed as issue 38441).
Fixes#38441
Change-Id: I4268da0d8b8cc51251eba6bd936110c8ab4c4e61
Reviewed-on: https://go-review.googlesource.com/c/go/+/229480
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, the small object sweeper will sweep until it finds a free
slot or there are no more spans of that size class to sweep. In dense
heaps, this can cause sweeping for a given size class to take
unbounded time, and gets worse with larger heaps.
This CL limits the small object sweeper to try at most 100 spans
before giving up and allocating a fresh span. Since it's already shown
that 100 spans are completely full at that point, the space overhead
of this fresh span is at most 1%.
This CL is based on an experimental CL by Austin Clements (CL 187817)
and is updated to be part of the mcentral implementation, gated by
go115NewMCentralImpl.
Updates #18155.
Change-Id: I37a72c2dcc61dd6f802d1d0eac3683e6642b6ef8
Reviewed-on: https://go-review.googlesource.com/c/go/+/229998
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently mcentral is implemented as a couple of linked lists of spans
protected by a lock. Unfortunately this design leads to significant lock
contention.
The span ownership model is also confusing and complicated. In-use spans
jump between being owned by multiple sources, generally some combination
of a gcSweepBuf, a concurrent sweeper, an mcentral or an mcache.
So first to address contention, this change replaces those linked lists
with gcSweepBufs which have an atomic fast path. Then, we change up the
ownership model: a span may be simultaneously owned only by an mcentral
and the page reclaimer. Otherwise, an mcentral (which now consists of
sweep bufs), a sweeper, or an mcache are the sole owners of a span at
any given time. This dramatically simplifies reasoning about span
ownership in the runtime.
As a result of this new ownership model, sweeping is now driven by
walking over the mcentrals rather than having its own global list of
spans. Because we no longer have a global list and we traditionally
haven't used the mcentrals for large object spans, we no longer have
anywhere to put large objects. So, this change also makes it so that we
keep large object spans in the appropriate mcentral lists.
In terms of the static lock ranking, we add the spanSet spine locks in
pretty much the same place as the mcentral locks, since they have the
potential to be manipulated both on the allocation and sweep paths, like
the mcentral locks.
This new implementation is turned on by default via a feature flag
called go115NewMCentralImpl.
Benchmark results for 1 KiB allocation throughput (5 runs each):
name \ MiB/s go113 go114 gotip gotip+this-patch
AllocKiB-1 1.71k ± 1% 1.68k ± 1% 1.59k ± 2% 1.71k ± 1%
AllocKiB-2 2.46k ± 1% 2.51k ± 1% 2.54k ± 1% 2.93k ± 1%
AllocKiB-4 4.27k ± 1% 4.41k ± 2% 4.33k ± 1% 5.01k ± 2%
AllocKiB-8 4.38k ± 3% 5.24k ± 1% 5.46k ± 1% 8.23k ± 1%
AllocKiB-12 4.38k ± 3% 4.49k ± 1% 5.10k ± 1% 10.04k ± 0%
AllocKiB-16 4.31k ± 1% 4.14k ± 3% 4.22k ± 0% 10.42k ± 0%
AllocKiB-20 4.26k ± 1% 3.98k ± 1% 4.09k ± 1% 10.46k ± 3%
AllocKiB-24 4.20k ± 1% 3.97k ± 1% 4.06k ± 1% 10.74k ± 1%
AllocKiB-28 4.15k ± 0% 4.00k ± 0% 4.20k ± 0% 10.76k ± 1%
Fixes#37487.
Change-Id: I92d47355acacf9af2c41bf080c08a8c1638ba210
Reviewed-on: https://go-review.googlesource.com/c/go/+/221182
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This change implements the spanSet data structure which is based off of
the gcSweepBuf data structure. While the general idea is the same (one
has two of these which one switches between every GC cycle; one to push
to and one to pop from), there are some key differences.
Firstly, we never have a need to iterate over this data structure so
delete numBlocks and block. Secondly, we want to be able to pop from the
front of the structure concurrently with pushes to the back. As a result
we need to maintain both a head and a tail and this change introduces an
atomic headTail structure similar to the one used by sync.Pool. It also
implements popfirst in a similar way.
As a result of this headTail, we need to be able to explicitly reset the
length, head, and tail when it goes empty at the end of sweep
termination, so add a reset method.
Updates #37487.
Change-Id: I5b8ad290ec32d591e3c8c05e496c5627018074f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/221181
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This change adds a global pool of spanSetBlocks to the spanSet data
structure and adds support for eagerly freeing these blocks back to the
pool if the block goes empty.
This change prepares us to use this data structure in more places in the
runtime by allowing reuse of spanSetBlock.
Updates #37487.
Change-Id: I0752226e3667a9e3e1d87c9b66edaedeae1ac23f
Reviewed-on: https://go-review.googlesource.com/c/go/+/221180
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This change copies the gcSweepBuf data structure into a new file and
renames it spanSet. It will serve as the basis for a heavily modified
version of the gcSweepBuf data structure for the new mcentral
implementation.
We move it into a separate file now for two reasons:
1. We will need both implementations as they will coexist simultaneously
for a time.
2. By creating it now in a new change it'll make future changes which
modify it easier to review (rather than introducing the new file then).
Updates #37487.
Change-Id: If80603cab6e813a1ee2e5ecd49dcde5d8045a6c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/221179
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Implement multi-control branches for riscv64, switching to using the BNEZ
pseudo-instruction when rewriting conditionals. This will allow for further
branch optimisations to later be performed via rewrites.
Change-Id: I7f2c69f3c77494b403f26058c6bc8432d8070ad0
Reviewed-on: https://go-review.googlesource.com/c/go/+/226399
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
type T [3]string
Prior to this change, we generated this equality alg for T:
func eqT(p, q *T) (r bool) {
for i := range *p {
if len(p[i]) == len(q[i]) {
} else {
return
}
}
for j := range *p {
if runtime.memeq(p[j].ptr, q[j].ptr, len(p[j])) {
} else {
return
}
}
return true
}
That first loop can be profitably eliminated;
it's cheaper to spell out 3 length equality checks.
We now generate:
func eqT(p, q *T) (r bool) {
if len(p[0]) == len(q[0]) &&
len(p[1]) == len(q[1]) &&
len(p[2]) == len(q[2]) {
} else {
return
}
for i := 0; i < len(p); i++ {
if runtime.memeq(p[j].ptr, q[j].ptr, len(p[j])) {
} else {
return
}
}
return true
}
We now also eliminate loops for small float arrays as well,
and for any array of size 1.
These cutoffs were selected to minimize code size on amd64
at this moment, for lack of a more compelling methodology.
Any smallish number would do.
The switch from range loops to plain for loops allowed me
to use a temp instead of a named var, which eliminated
a pointless argument to checkAll.
The code to construct them is also a bit clearer, in my opinion.
Change-Id: I1bdd8ee4a2739d00806e66b17a4e76b46e71231a
Reviewed-on: https://go-review.googlesource.com/c/go/+/230210
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add linux/{ppc64,ppc64le} and aix/ppc64 arch support for the new
dodata() phase.
This completes the picture in terms of architecture support for the
new dodata(), but to be safe this patch leaves the command line flag
in place there are problems on the builders (especially given that we
have a dead aix-ppc64 builder).
Change-Id: I78da615c3b540d8925ed7b3226e199280eb7451d
Reviewed-on: https://go-review.googlesource.com/c/go/+/229983
Reviewed-by: Cherry Zhang <cherryyz@google.com>
type T [8]string
Prior to this change, we generated this equality algorithm for T:
func eqT(p, q *T) (r bool) {
for i := range *p {
if p[i] == q[i] {
} else {
return
}
}
return true
}
This change splits this into two loops, so that we can do the
cheap (length) half early and only then do the expensive (contents) half.
We now generate:
func eqT(p, q *T) (r bool) {
for i := range *p {
if len(p[i]) == len(q[i]) {
} else {
return
}
}
for j := range *p {
if runtime.memeq(p[j].ptr, q[j].ptr, len(p[j])) {
} else {
return
}
}
return true
}
The generated code is typically ~17% larger because it contains
two loops instead of one. In the future, we might want to unroll
the first loop when the array is small.
Change-Id: I26b2793b90ec6aff21766a411b15a4ff1096c03f
Reviewed-on: https://go-review.googlesource.com/c/go/+/230209
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
type T [8]interface{}
Prior to this change, we generated this equality algorithm for T:
func eqT(p, q *T) bool {
for i := range *p {
if p[i] != q[i] {
return false
}
}
return true
}
This change splits this into two loops, so that we can do the
cheap (type) half early and only then do the expensive (data) half.
We now generate:
func eqT(p, q *T) (r bool) {
for i := range *p {
if p[i].type == q[i].type {
} else {
return
}
}
for j := range *p {
if runtime.efaceeq(p[j].type, p[j].data, q[j].data) {
} else {
return
}
}
return true
}
The use of a named return value and a bare return is to work
around some typechecking problems that stymied me.
The structure of using equals and else (instead of not equals and then)
was for implementation convenience and clarity. As a bonus,
it generates slightly shorter code on AMD64, because zeroing a register
to return is cheaper than writing $1 to it.
The generated code is typically ~17% larger because it contains
two loops instead of one. In the future, we might want to unroll
the first loop when the array is small.
Change-Id: I5b2c8dd3384852f085c4f3e1f6ad20bc5ae59062
Reviewed-on: https://go-review.googlesource.com/c/go/+/230208
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
type T struct {
s interface{}
i int
}
Prior to this change, we generated this equality algorithm for T:
func eqT(p, q *T) bool {
return p.s.type == q.s.type &&
runtime.efaceeq(p.s.type, p.s.data, q.s.data) &&
p.i == q.i
}
This change splits the two halves of the interface equality,
so that we can do the cheap (type) half early and the expensive
(data) half late. We now generate:
func eqT(p, q *T) bool {
return p.s.type == q.s.type &&
p.i == q.i &&
runtime.efaceeq(p.s.type, p.s.data, q.s.data)
}
The generated code tends to be a bit smaller. Examples:
go/ast
.eq."".ForStmt 306 -> 304 (-0.65%)
.eq."".TypeAssertExpr 221 -> 219 (-0.90%)
.eq."".TypeSwitchStmt 228 -> 226 (-0.88%)
.eq."".ParenExpr 150 -> 148 (-1.33%)
.eq."".IndexExpr 221 -> 219 (-0.90%)
.eq."".SwitchStmt 228 -> 226 (-0.88%)
.eq."".RangeStmt 334 -> 332 (-0.60%)
Change-Id: Iec9e24f214ca772416202b9fb9252e625c22380e
Reviewed-on: https://go-review.googlesource.com/c/go/+/230207
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Refactor out creating the two Nodes needed to check interface equality.
Preliminary work to other optimizations.
Passes toolstash-check.
Change-Id: Id6b39e8e78f07289193423d0ef905d70826acf89
Reviewed-on: https://go-review.googlesource.com/c/go/+/230206
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
type T struct {
s string
i int
}
Prior to this change, we generated this equality algorithm for T:
func eqT(p, q *T) bool {
return len(p.s) == len(q.s) &&
runtime.memequal(p.s.ptr, q.s.ptr, len(p.s)) &&
p.i == q.i
}
This change splits the two halves of the string equality,
so that we can do the cheap (length) half early and the expensive
(contents) half late. We now generate:
func eqT(p, q *T) bool {
return len(p.s) == len(q.s) &&
p.i == q.i &&
runtime.memequal(p.s.ptr, q.s.ptr, len(p.s))
}
The generated code for these functions tends to be a bit shorter. Examples:
runtime
.eq."".Frame 274 -> 272 (-0.73%)
.eq."".funcinl 249 -> 247 (-0.80%)
.eq."".modulehash 207 -> 205 (-0.97%)
Change-Id: I4efac9f7d410f0a11a94dcee2bf9c0b49b60e301
Reviewed-on: https://go-review.googlesource.com/c/go/+/230205
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Refactor out creating the two Nodes needed to check string equality.
Preliminary work to other optimizations.
Passes toolstash-check.
Change-Id: I72e824dac904e579b8ba9a3669a94fa1471112d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/230204
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We only generate if statements via CondBreak, which is nice as the
control flow is simple and easy to work with. It seems like the If type
was added but never used, so remove it to avoid confusion.
We had a TODO about replacing CondBreak with If instead. I gave that a
try, but it doesn't seem worth the effort. The code gets more complex
and we don't really win anything in return.
While at it, don't use op strings as format strings in exprf. This
doesn't cause any issue at the moment, but it's best to be explicit
about the operator not containing any formatting verbs.
Change-Id: Ib59ad72d3628bf91594efc609e222232ad1e8748
Reviewed-on: https://go-review.googlesource.com/c/go/+/230257
Reviewed-by: Keith Randall <khr@golang.org>
The ReadOnly attribute was used to do copy on write when applying
relocations to symbols with read-only backing stores. Now that we
always apply relocations in the output buffer (mmap or heap), it
is always writeable. No need to tamper with the ReadOnly
attribute anymore.
Wasm is an exception, where we don't copy symbol contents to the
output buffer first. Do copy-on-write there.
This is in preparation of converting reloc to using the loader.
Change-Id: I15e53b7c162b9124e6689dfd8eb45cbe2ffd7153
Reviewed-on: https://go-review.googlesource.com/c/go/+/229991
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Currently, we run Asmb before reloc, except on Wasm, where the
order is reversed. However, Asmb is no-op on Wasm. So we can
always run Asmb first.
Change-Id: Ifb8989d8150ebdd5777deb05cbccec16f8e36d82
Reviewed-on: https://go-review.googlesource.com/c/go/+/229990
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
They also don't need to do anything for Adddynrel. So we can just
enable it.
Change-Id: If85fceca63a7b3cb5a09e5db224c3018060e86de
Reviewed-on: https://go-review.googlesource.com/c/go/+/229993
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Recreation of CL 229863 that was removed from the repo because it
included the linker binary.
Change-Id: I5e96afa079b1217df6e7cba63a107546bd96ef76
Reviewed-on: https://go-review.googlesource.com/c/go/+/230028
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It is supposed to work around symbol movement in machosymorder.
But machosymorder doesn't actually move symbols around.
Change-Id: Ibdc2ad41aaa8cd49e865088aa1ddb7ab399736cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/230279
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The symbol alignment is set based on its size. In dynreloc2
symbol size may change (e.g. elfdynhash2). So the alignment must
be set after dynreloc2.
Noticed this while debugging nondeterministic build on Solaris.
Idx Name Size VMA LMA File off Algn
8 .hash 000000c8 000000000048add2 000000000048add2 0008add2 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
This doesn't look right, as the section address is not a multiple
of its alignment.
Change-Id: I23534cbc59695b7bc241838173fcc71dde95b195
Reviewed-on: https://go-review.googlesource.com/c/go/+/230278
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Add elf/ARM arch support for the new dodata() phase.
Change-Id: Iadd772b01036c6c5be95bcc6017f6c05d45a24c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/229868
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Apply strong aux typing to lowering rules that do not require
modification beyond substituting -> for =>. Other lowering rules
and all the optimization rules will follow. I'm breaking it up
to allow toolstash-check to pass on the big CLs.
Passes toolstash-check -all.
Change-Id: I6f1340058a8eb5a1390411e59fcbea9d7f777e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/229400
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Convert some Move and Zero Lowering rules to strongly-typed versions.
Passes toolstash-check.
Change-Id: Icaabe05e206d59798e5883a90e9a33bb30270b13
Reviewed-on: https://go-review.googlesource.com/c/go/+/229919
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The commuteDepth variable is no longer necessary; remove it.
Else branches after a log.Fatal call are unnecessary.
Also make the unbalanced return an integer, so we can differentiate
positive from negative cases. We only want to continue a rule with the
following lines if this balance is positive, for example.
While at it, make the balance loop stop when it goes negative, to not
let ")(" seem balanced.
Change-Id: I8aa313343ca5a2f07f638b62a0398fdf108fc9eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/228822
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Ensures that a canceled client request for Switching Protocols
(e.g. h2c, Websockets) will cause the underlying connection to
be terminated.
Adds a goroutine in handleUpgradeResponse in order to select on
the incoming client request's context and appropriately cancel it.
Fixes#35559
Change-Id: I1238e18fd4cce457f034f78d9cdce0e7f93b8bf6
GitHub-Last-Rev: 3629c78493
GitHub-Pull-Request: golang/go#38021
Reviewed-on: https://go-review.googlesource.com/c/go/+/224897
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Everywhere else is using "cancellation"
The reasoning is mentioned in 170060
> Though there is variation in the spelling of canceled,
> cancellation is always spelled with a double l.
>
> Reference: https://www.grammarly.com/blog/canceled-vs-cancelled/
Change-Id: Ifc97c6785afb401814af77c377c2e2745ce53c5a
GitHub-Last-Rev: 05edd7477d
GitHub-Pull-Request: golang/go#38662
Reviewed-on: https://go-review.googlesource.com/c/go/+/230200
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
