This change splits the finalizer and cleanup queues and implements a new
lock-free blocking queue for cleanups. The basic design is as follows:
The cleanup queue is organized in fixed-sized blocks. Individual cleanup
functions are queued, but only whole blocks are dequeued.
Enqueuing cleanups places them in P-local cleanup blocks. These are
flushed to the full list as they get full. Cleanups can only be enqueued
by an active sweeper.
Dequeuing cleanups always dequeues entire blocks from the full list.
Cleanup blocks can be dequeued and executed at any time.
The very last active sweeper in the sweep phase is responsible for
flushing all local cleanup blocks to the full list. It can do this
without any synchronization because the next GC can't start yet, so we
can be very certain that nobody else will be accessing the local blocks.
Cleanup blocks are stored off-heap because the need to be allocated by
the sweeper, which is called from heap allocation paths. As a result,
the GC treats cleanup blocks as roots, just like finalizer blocks.
Flushes to the full list signal to the scheduler that cleanup goroutines
should be awoken. Every time the scheduler goes to wake up a cleanup
goroutine and there were more signals than goroutines to wake, it then
forwards this signal to runtime.AddCleanup, so that it creates another
goroutine the next time it is called, up to gomaxprocs goroutines.
The signals here are a little convoluted, but exist because the sweeper
and the scheduler cannot safely create new goroutines.
For #71772.
For #71825.
Change-Id: Ie839fde2b67e1b79ac1426be0ea29a8d923a62cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/650697
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Currently TestCertCache will busy loop waiting for a cleanup (in the
runtime.AddCleanup sense) to execute. If we ever get into this busy
loop, then on single-threaded platforms like js/wasm, we'll end up
_always_ timing out.
This doesn't happen right now because we're getting lucky. The finalizer
goroutine is scheduled into the runnext slot with 'ready' and is thus
scheduled immediately after the GC call. In a follow-up CL, scheduling
cleanup goroutines becomes less aggressive, and thus this test fails.
Although perhaps that CL should schedule cleanup goroutines more
aggressively, the test is still technically buggy, because it expects
busy loops like this to call into the scheduler, but that won't happen
on certain platforms.
Change-Id: I8efe5975be97f4314aec1c8c6e9e22f396be9c94
Reviewed-on: https://go-review.googlesource.com/c/go/+/670755
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
go get golang.org/x/mod@9d33331
go mod tidy
go mod vendor
For #42965
Change-Id: Ib741c96be53214c35058a564116688e7122a205a
Reviewed-on: https://go-review.googlesource.com/c/go/+/670975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Using the same method CleanPatterns harmonizes further accepted format of patterns in go command.
Fixes#24233
Change-Id: Idb8176df3a7949b16764cd6ea51d7a8966799e42
Reviewed-on: https://go-review.googlesource.com/c/go/+/669775
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The default value is the value obtained when
no environment variables are set and go env -w is not used.
In the past,
we used the current value
(may be modified by an environment variable to a non-default value),
error was used as the default value.
For #69994
Change-Id: Iead3a6cacd04dc51a094ffb9f7bb7553320fcd78
Reviewed-on: https://go-review.googlesource.com/c/go/+/621995
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The stated goal for pkgbits is to implement encoding / decoding of
primitives. However, pkgbits has knowledge of high-level details like
elements, sections, and file layout.
This change starts to clarify pkgbits by paring back documentation to
only those concepts which pkgbits owns. Further CLs are needed to shift
away logic that pkgbits should not own.
Change-Id: Id93003d080f58ffbd6327e2db1a4878500511619
Reviewed-on: https://go-review.googlesource.com/c/go/+/670176
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
It's the job of the last sweeper to emit the GC pacer trace. The last
sweeper can identify themselves by reducing the count of sweepers, and
also seeing that there's no more sweep work.
Currently this identification is broken, however, because the last
sweeper doesn't check the state they just transitioned sweeping into,
but rather the state they transitioned from (one sweeper, no sweep work
left). By design, it's impossible to transition *out* of this state,
except for another GC to start, but that doesn't take this codepath.
This means lines like
pacer: sweep done at heap size ...
were missing from the gcpacertrace output for a long time.
This change fixes this problem by having the last sweeper check the
state they just transitioned sweeping to, instead of the state they
transitioned from.
Change-Id: I44bcd32fe2c8ae6ac6c21ba6feb2e7b9e17f60cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/670735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
And use it in crypto/x509. This allows people to implement single-shot
signers which do the hashing themselves.
Fixes#63405
Change-Id: I038c2e10f77b050b6136c4c0a5b031cb416f59aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/654375
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The RISC-V Instruction Set Manual Volume states that "for vadc and
vsbc, the instruction encoding is reserved if the destination vector
register is v0". The assembler currently allows instructions like
VADCVVM V1, V2, V0, V0
to be assembled. It's not clear what the behaviour of such
instructions will be on target hardware so it's best to disallow
them.
For reference, binutils (2.44-3.fc42) allows the instruction
vadc.vvm v0, v4, v8, v0
to be assembled and the instruction actually executes on a Banana PI
F3 without crashing. However, clang (20.1.2) refuses to assemble the
instruction, producing the following error.
error: the destination vector register group cannot be V0
vadc.vvm v0, v4, v8, v0
^
Change-Id: Ia913cbd864ae8dbcf9227f69b963c93a99481cff
Reviewed-on: https://go-review.googlesource.com/c/go/+/669315
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
The encodings for the riscv64 special operands SPOP_MF2 and SPOP_MF8
are incorrect, i.e., their values are swapped. This leads to
incorrect encodings for the VSETVLI and VSETIVLI instructions. The
assembler currently encodes
VSETVLI X10, E32, MF8, TA, MA, X12
as
VSETVLI X10, E32, MF2, TA, MA, X12
We update the encodings for SPOP_MF2 and SPOP_MF8 so that they match
the LMUL table in section "31.3.4. Vector type register, vtype" of
the "RISC-V Instruction Set Manual Volume 1".
Change-Id: Ic73355533d7c2a901ee060b35c2f7af6d58453e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/670016
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Change-Id: I17568a898ea8514c7b32d2f48c44365ae37cf898
Reviewed-on: https://go-review.googlesource.com/c/go/+/670195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Previous fix in CL 667715 wasn't correct for aix.
Change-Id: I44042786079463967165507b15756cf24b9a213a
Reviewed-on: https://go-review.googlesource.com/c/go/+/668036
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
We've settled on calling the group of goroutines started by
synctest.Run a "bubble". At the time the runtime implementation
was written, I was still calling this a "group". Update the code
to match the current terminology.
Change-Id: I31b757f31d804b5d5f9564c182627030a9532f4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/670135
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Once the goroutine started by synctest.Run exits, stop advancing
the fake clock in its bubble. This avoids confusing situations
where a bubble remains alive indefinitely while a background
goroutine reads from a time.Ticker or otherwise advances the clock.
For #67434
Change-Id: Id608ffe3c7d7b07747b56a21f365787fb9a057d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/662155
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
This will make future uses of the map faster because the probe
sequences will likely be shorter.
Change-Id: If10f3af49a5feaff7d1b82337bbbfb93bcd9dcb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/633076
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Go 1.22 promised to remove the setting in a future release once the
semantics of runtime-internal lock contention matched that of
sync.Mutex. That work is done, remove the setting.
Previously reviewed as https://go.dev/cl/585639.
For #66999
Change-Id: I9fe62558ba0ac12824874a0bb1b41efeb7c0853f
Reviewed-on: https://go-review.googlesource.com/c/go/+/668995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Have the test use the same clock (cputicks) as the profiler, and use the
test's own measurements as hard bounds on the magnitude to expect in the
profile.
Compare the depiction of two users of the same lock: one where the
critical section is fast, one where it is slow. Confirm that the profile
shows the slow critical section as a large source of delay (with #66999
fixed), rather than showing the fast critical section as a large
recipient of delay.
Previously reviewed as https://go.dev/cl/586237.
For #66999
Change-Id: Ic2d78cc29153d5322577d84abdc448e95ed8f594
Reviewed-on: https://go-review.googlesource.com/c/go/+/667616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Correct how the mutex contention profile reports on runtime-internal
mutex values, to match sync.Mutex's semantics.
Decide at the start of unlock2 whether we'd like to collect a contention
sample. If so: Opt in to a slightly slower unlock path which avoids
accidentally accepting blame for delay caused by other Ms. Release the
lock before doing an O(N) traversal of the stack of waiting Ms, to
calculate the total delay to those Ms that our critical section caused.
Report that, with the current callstack, in the mutex profile.
Fixes#66999
Change-Id: I561ed8dc120669bd045d514cb0d1c6c99c2add04
Reviewed-on: https://go-review.googlesource.com/c/go/+/667615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
The race feature depends on llvm. And support for building the tsan library on
linux/loong64 has been added in this patch [1], which has been merged into the
branch main and has landed in llvm18.
The support for linux/loong64 in racebuild has been implemented in CL 655775,
now racebuild can successfully build race_linux_loong64.syso [2].
[1]: https://github.com/llvm/llvm-project/pull/72819
[2]: racebuild -platforms linux/loong64 -cherrypick 'refs/changes/16/543316/10' \
-rev 83fe85115da9dc25fa270d2ea8140113c8d49670 \
-goroot /home/golang/src/go
Co-authored-by: Xiaolin Zhao <zhaoxiaolin@loongson.cn>
Change-Id: If389318215476890295ed771297c6c088cfc84b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/543316
Reviewed-by: Qiqi Huang <huangqiqi@loongson.cn>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
When synctest.Run panics due to every goroutine in the bubble being
blocked, print a stack trace for every goroutine in the bubble.
For #67434
Change-Id: Ie751c2ee6fa136930b18f4bee0277ff30da46905
Reviewed-on: https://go-review.googlesource.com/c/go/+/645719
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The current Error documentation is vacuous and doesn't say anything
about what this interface is actually for. Expand to include its meaning
and why it might be used.
Change-Id: I6a6a636cbd5f5788cb9d1a88845de16b98f7424b
Reviewed-on: https://go-review.googlesource.com/c/go/+/670635
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Replace the usage of runtime.SetFinalizer with runtime.AddCleanup in
the certificate cache.
Updates #70907
Change-Id: Ieab6ff88dbc4083f11c1b475f11bd61521dbc638
Reviewed-on: https://go-review.googlesource.com/c/go/+/664275
Auto-Submit: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: Ia1909a31dececd7d883ca3bddc6293dd81aee93e
Reviewed-on: https://go-review.googlesource.com/c/go/+/669435
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change moves the unique package away from using a concurrent map
and instead toward a bespoke concurrent canonicalization map. The map
holds all its keys weakly, though keys may be looked up by value. The
result is the strong pointer for the canonical value. Entries in the map
are automatically cleaned up once the canonical reference no longer
exists.
Why do this? There's a problem with the current implementation when it
comes to chains of unique.Handle: because the unique map will have a
unique.Handle stored in its keys, each nested handle must be cleaned up
1 GC at a time. It takes N GC cycles, at minimum, to clean up a nested
chain of N handles. This implementation, where the *only* value in the
set is weakly-held, does not have this problem. The entire chain is
dropped at once.
The canon map implementation is a stripped-down version of HashTrieMap.
The weak set implementation also has lower memory overheads by virtue of
the fact that keys are all stored weakly. Whereas the previous map had
both a T and a weak.Pointer[T], this *only* has a weak.Pointer[T].
The canonicalization map is a better abstraction overall and
dramatically simplifies the unique.Make code.
While we're here, delete the background goroutine and switch to
runtime.AddCleanup. This is a step toward fixing #71772. We still need
some kind of back-pressure mechanism, which will be implemented in a
follow-up CL.
For #71772.
Fixes#71846.
Change-Id: I5b2ee04ebfc7f6dd24c2c4a959dd0f6a8af24ca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/650256
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>
Change-Id: Id194a42645d1da6440558bf12dc252f347072f86
Reviewed-on: https://go-review.googlesource.com/c/go/+/670175
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
For #73526
Change-Id: I06d8ae9080695745db68a51635faa0b244c1760e
Reviewed-on: https://go-review.googlesource.com/c/go/+/670155
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
The doInRoot function operates on a path split into components.
The final path component retained any trailing path separator
characters, to permit operations in a Root to retain the
trailing-separator behavior of non-Root operations. However,
doInRoot failed to take trailing separators into account
when checking for .. path components.
This could permit opening the parent directory of the Root
with a path ending in "../".
Change the split path to never include path separators in
components, and handle trailing separators independently
of the split path.
Thanks to Dan Sebastian Thrane of SDU eScience Center for
reporting this issue.
Fixes#73555
Fixes CVE-2025-22873
Change-Id: I9a33a145c22f5eb1dd4e4cafae5fcc61a8d4f0d4
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2160
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/670036
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
I think that SectionKind better conveys the original intent here, and
goes nicely with codifying section relative indices.
Change-Id: I96a245e67295a5f9f8e462756a14f60eccec6862
Reviewed-on: https://go-review.googlesource.com/c/go/+/668538
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Change-Id: I214eb97ef3b11a6de8584498f2df4baff1903e1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/668537
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This creates the infrastructure needed to record compiler panics
induced somewhere beneath a declaration. For now, this is turned
off via a flag.
This does not yet use the position information for better error
messages. That is moved off to a separate CL.
Change-Id: I6b44135a84ebd2f4c0141408ba9228d72c497d55
Reviewed-on: https://go-review.googlesource.com/c/go/+/664475
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, the `source` method in `slog.Record` is not accessible to
custom handlers, requiring developers to re-implement logic for
retrieving source location information. This commit exports the `source`
method as `Source`, enabling consistent access for custom logging
handlers and reducing code redundancy.
Fixes#70280
Change-Id: I3eb3bc60658abc5de95697a10bddd11ab54c6e13
GitHub-Last-Rev: bd81afe5a5
GitHub-Pull-Request: golang/go#70281
Reviewed-on: https://go-review.googlesource.com/c/go/+/626976
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I71cc0db153c559d4c5b48d1d744daf16deffe6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/668536
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
So we can avoid using a TEST where it isn't needed.
Currently only implemented for ADD{Q,L}const.
Change-Id: Ia9c4c69bb6033051a45cfd3d191376c7cec9d423
Reviewed-on: https://go-review.googlesource.com/c/go/+/669875
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Line directives should not affect the way Comments get grouped
into CommentGroups.
Change-Id: I9aa4b558cb1333b32be692e8720291d0e6961cae
GitHub-Last-Rev: de867b27bf
GitHub-Pull-Request: golang/go#69133
Reviewed-on: https://go-review.googlesource.com/c/go/+/609515
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The runtime poller and os.NewFile recently gained support for
disassociating the handle from the runtime poller IOCP (see CL 664455).
This was the main blocker for allowing the conversion between *os.File
and net.Conn.
Implementing the conversion is now trivial. The only remaining work,
implemented in this CL, is improving os.NewFile to also support
socket handles and updating some build tags so that Windows can share
almost the same net's File implementation as Unix.
There is one important limitation, though: the duplicated socket handle
returned by the various File methods in the net package is not
usable on other process. If someone needs to pass a socket handle to
another process, they should manually call the WSADuplicateSocket
Windows API passing the process ID of the target process.
Fixes#9503.
Fixes#10350.
Updates #19098.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race,gotip-windows-amd64-longtest,gotip-windows-arm64
Change-Id: Ic43cadaac2662b925d57a9d362ddc7ae21d1b56e
Reviewed-on: https://go-review.googlesource.com/c/go/+/668195
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Corollary to CL 669615.
morestack uses the frame pointer from g0.sched.bp. This doesn't really
make any sense. morestack wasn't called by whatever used g0 last, so at
best unwinding will get misleading results.
For #63630.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest
Change-Id: I6a6a636c3a2994eb88f890c506c96fd899e993a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/669616
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On arm64, systemstack restores the frame pointer from g0.sched to R29
prior to calling the callback. That doesn't really make any sense. The
frame pointer value in g0.sched is some arbitrary BP from a prior
context save, but that is not the caller of systemstack.
amd64 does not do this. In fact, it leaves BP completely unmodified so
frame pointer unwinders like gdb can walk through the systemstack frame
and continue traceback on the caller's stack. Unlike mcall, systemstack
always returns to the original goroutine, so that is safe.
We should do the same on arm64.
For #63630.
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest
Change-Id: I6a6a636c35d321dd5d7dc1c4d09e29b55b1ab621
Reviewed-on: https://go-review.googlesource.com/c/go/+/669236
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
On amd64, mcall leaves BP untouched, so the callback will push BP,
connecting the g0 stack to the calling g stack. This seems OK (frame
pointer unwinders like Linux perf can see what user code called into the
scheduler), but the "scheduler" part is problematic.
mcall is used when calling into the scheduler to deschedule the current
goroutine (e.g., in goyield). Once the goroutine is descheduled, it may
be picked up by another M and continue execution. The other thread is
mutating the goroutine stack, but our M still has a frame pointer
pointing to the goroutine stack.
A frame pointer unwinder like Linux perf could get bogus values off of
the mutating stack. Note that though the execution tracer uses
framepointer unwinding, it never unwinds a g0, so it isn't affected.
Clear the frame pointer in mcall so that unwinding always stops at
mcall.
On arm64, mcall stores the frame pointer from g0.sched.bp. This doesn't
really make any sense. mcall wasn't called by whatever used g0 last, so
at best unwinding will get misleading results (e.g., it might look like
cgocallback calls mcall?).
Also clear the frame pointer on arm64.
Other architectures don't use frame pointers.
For #63630.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-arm64-longtest
Change-Id: I6a6a636cb6404f3c95ecabdb969c9b8184615cee
Reviewed-on: https://go-review.googlesource.com/c/go/+/669615
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
The existing implementation lacks the Status function for retrieving VCS build
information for Subversion. As a consequence, binaries aren't stamped with the
Revision, CommitTime and Uncommitted information from SVN repositories.
This change provides the svnStatus function and retrieves the information by
running svn info and svn status commands.
Fixes#73444
Change-Id: Ie6d95ffbb3a3c580cc42128ad1f8d82a869c91f2
GitHub-Last-Rev: 3472222865
GitHub-Pull-Request: golang/go#73446
Reviewed-on: https://go-review.googlesource.com/c/go/+/666875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Our current parallel mark algorithm suffers from frequent stalls on
memory since its access pattern is essentially random. Small objects
are the worst offenders, since each one forces pulling in at least one
full cache line to access even when the amount to be scanned is far
smaller than that. Each object also requires an independent access to
per-object metadata.
The purpose of this change is to improve garbage collector performance
by scanning small objects in batches to obtain better cache locality
than our current approach. The core idea behind this change is to defer
marking and scanning small objects, and then scan them in batches
localized to a span.
This change adds scanned bits to each small object (<=512 bytes) span in
addition to mark bits. The scanned bits indicate that the object has
been scanned. (One way to think of them is "grey" bits and "black" bits
in the tri-color mark-sweep abstraction.) Each of these spans is always
8 KiB and if they contain pointers, the pointer/scalar data is already
packed together at the end of the span, allowing us to further optimize
the mark algorithm for this specific case.
When the GC encounters a pointer, it first checks if it points into a
small object span. If so, it is first marked in the mark bits, and then
the object is queued on a work-stealing P-local queue. This object
represents the whole span, and we ensure that a span can only appear at
most once in any queue by maintaining an atomic ownership bit for each
span. Later, when the pointer is dequeued, we scan every object with a
set mark that doesn't have a corresponding scanned bit. If it turns out
that was the only object in the mark bits since the last time we scanned
the span, we scan just that object directly, essentially falling back to
the existing algorithm. noscan objects have no scan work, so they are
never queued.
Each span's mark and scanned bits are co-located together at the end of
the span. Since the span is always 8 KiB in size, it can be found with
simple pointer arithmetic. Next to the marks and scans we also store the
size class, eliminating the need to access the span's mspan altogether.
The work-stealing P-local queue is a new source of GC work. If this
queue gets full, half of it is dumped to a global linked list of spans
to scan. The regular scan queues are always prioritized over this queue
to allow time for darts to accumulate. Stealing work from other Ps is a
last resort.
This change also adds a new debug mode under GODEBUG=gctrace=2 that
dumps whole-span scanning statistics by size class on every GC cycle.
A future extension to this CL is to use SIMD-accelerated scanning
kernels for scanning spans with high mark bit density.
For #19112. (Deadlock averted in GOEXPERIMENT.)
For #73581.
Change-Id: I4bbb4e36f376950a53e61aaaae157ce842c341bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/658036
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TestIssue64958 takes a while, so it's not worth running both without
and with -check flag. The others are fast, but there's still no good
reason to run anything but TestCheck when the -check flag is on.
Change-Id: I13ebb90e3c863006f21441909b05364e1b316ed6
Reviewed-on: https://go-review.googlesource.com/c/go/+/668656
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Add support for vector permutation instructions to the RISC-V assembler.
This includes integer scalar move, floating point scalar move, slide up
and slide down, register gather, compression and whole vector register
move instructions.
Change-Id: I1da9f393091504fd81714006355725b8b9ecadea
Reviewed-on: https://go-review.googlesource.com/c/go/+/646780
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Add support for vector mask instructions to the RISC-V assembler.
These allow manipulation of vector masks and include mask register
logical instructions, population count and find-first bit set
instructions.
Change-Id: I3ab3aa0f918338aee9b37ac5a2b2fdc407875072
Reviewed-on: https://go-review.googlesource.com/c/go/+/646779
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Add support for vector reduction instructions to the RISC-V assembler,
including single-width integer reduction, widening integer reduction,
single-width floating-point reduction and widening floating-point
reduction.
Change-Id: I8f17bef11389f3a017e0430275023fc5d75936e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/646778
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Michael Anthony Knyszek
Jakub Ciolek
Sam Thanawalla
Constantin Konstantinidis
qiulaidongfeng
Mark Freeman
Roland Shoemaker
Mark Ryan
Xiaolin Zhao
Rhys Hiltner
Keith Randall
Damien Neil
Guoqi Chen
Michael Pratt
Carlos Amedee
cuishuang
Ernesto Alejandro Santana Hidalgo
tdakkota
Mateusz Poliwczak
qmuntal
Russ Cox
Stefan Schlosser
Dmitri Shuralyov
Joel Sing