| Age | Commit message (Collapse) | Author |
|---|
|
osyield is called in code paths that are not allowed to split
stack, e.g. casgstatus called from entersyscall/exitsyscall.
It is nosplit on all other platforms. Mark it nosplit on OpenBSD
as well.
Change-Id: I3fed5d7f58b3d50610beca6eed2c7e902b8ec52c
Reviewed-on: https://go-review.googlesource.com/c/go/+/319969
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
|
|
Don't add them to files in vendor and cmd/vendor though. These will be
pulled in by updating the respective dependencies.
For #41184
Change-Id: Icc57458c9b3033c347124323f33084c85b224c70
Reviewed-on: https://go-review.googlesource.com/c/go/+/319389
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
As a follow up to an earlier change[1] to add ARMv8+LSE instructions in
the compiler generated atomic intrinsics, make the same change in the
runtime library. Since not all ARMv8 systems support LSE instructions,
they are protected by a feature-flag branch.
[1]: golang.org/cl/234217 commit: ecc3f5112eba
Change-Id: I0e2fb22e78d5eddb6547863667a8865946679a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/310591
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
|
|
It is valid to see SPWRITE functions at the top of a GC stack traceback,
in the case where they self-preempted during the stack growth check
and haven't actually modified SP in a traceback-unfriendly manner yet.
The current check is therefore too aggressive.
isAsyncSafePoint is taking care of not async-preempting SPWRITE functions
because it doesn't async-preempt any assembly functions at all.
But perhaps it will in the future.
To keep a check that SPWRITE assembly functions are not async-preempted,
add one in preemptPark. Then relax the check in traceback to avoid
triggering on self-preempted SPWRITE functions.
The long and short of this is that the assembly we corrected in x/crypto
issue #44269 was incredibly dodgy but not technically incompatible with
the Go runtime. After this change, the original x/crypto assembly no longer
causes GC traceback crashes during "GOGC=1 go test -count=1000".
But we'll still leave the corrected assembly.
This also means that we don't need to worry about diagnosing SPWRITE
assembly functions that may exist in the wild. They will be skipped for
async preemption and no harm no foul.
Fixes #44269, which was open pending some kind of check for
bad SPWRITE functions in the wild. (No longer needed.)
Change-Id: I6000197b62812bbd2cd92da28eab422634cf75a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317669
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Change-Id: I12c0befc5772a5c902a55aeb06a30ec7a34a3bd6
GitHub-Last-Rev: 7d41e1bcb9f6304e1b868701740279e845c99a66
GitHub-Pull-Request: golang/go#46112
Reviewed-on: https://go-review.googlesource.com/c/go/+/319053
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
As a cleanup, golang.org/cl/307914 unintentionally caused the idle GC
work recheck to drop sched.lock between acquiring a P and committing to
keep it (once a worker G was found).
This is unsafe, as releasing a P requires extra checks once sched.lock
is taken (such as for runSafePointFn). Since checkIdleGCNoP does not
perform these extra checks, we can now race with other users.
In the case of #45975, we may hang with this sequence:
1. M1: checkIdleGCNoP takes sched.lock, gets P1, releases sched.lock.
2. M2: forEachP takes sched.lock, iterates over sched.pidle without
finding P1, releases sched.lock.
3. M1: checkIdleGCNoP puts P1 back in sched.pidle.
4. M2: forEachP waits forever for P1 to run the safePointFn.
Change back to the old behavior of releasing sched.lock only after we
are certain we will keep the P. Thus if we put it back its removal from
sched.pidle was never visible.
Fixes #45975
For #45916
For #45885
For #45884
Change-Id: I191a1800923b206ccaf96bdcdd0bfdad17b532e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318569
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
openbsd/mips64 is now the only openbsd port that uses non-libc syscall - revise
build tags to reflect this.
Update #36435
Change-Id: I357b2dd2926d058e25e618fcca42c388587598a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317919
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Recently some tsan tests were enabled on ppc64le which had not
been enabled before. This resulted in failures on systems with
tsan available, and while debugging it was determined that
there were other issues related to the use of signals with cgo.
Signals were not being forwarded within programs linked against
libtsan because the nocgo sigaction was being called for ppc64le
with or without cgo. Adding callCgoSigaction and calling that
allows signals to be registered so that signal forwarding works.
For linux-ppc64 and aix-ppc64, this won't change. On linux-ppc64
there is no cgo. I can't test aix-ppc64 so those owners can enable
it if they want.
In reviewing comments about sigtramp in sys_linux_arm64 it was
noted that a previous issue in arm64 due to missing callee save
registers could also be a problem on ppc64x, so code was added
to save and restore those.
Also, the use of R31 as a temp register in some cases caused an
issue since it is a nonvolatile register in C and was being clobbered
in cases where the C code expected it to be valid. The code sequences to
load these addresses were changed to avoid the use of R31 when loading
such an address.
To get around a vet error, the stubs_ppc64x.go file in runtime
was split into stubs_ppc64.go and stubs_ppc64le.go.
Updates #45040
Change-Id: Ia4ecff950613cbe1b89471790b1d3819d5b5cfb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306369
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
|
|
Go 1.17 requires macOS 10.13 or later. Thus, drop the special cases for
the darwin-amd64-10_12 builder added in CL 202618.
Updates #22019
Updates #23011
Updates #32919
Change-Id: Idef11c213dfb25fd002b7cda6d425cf2e26a2e06
Reviewed-on: https://go-review.googlesource.com/c/go/+/318329
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Encode the length of type names and tags in a varint encoding
instead of a fixed 2-byte encoding. This allows lengths longer
than 65535 (which can happen for large unnamed structs).
Removed the alignment check for #14962, it isn't relevant any more
since we're no longer reading pointers directly out of this data
(it is encoded as an offset which is copied out bytewise).
Fixes #44155
Update #14962
Change-Id: I6084f6027e5955dc16777c87b0dd5ea2baa49629
Reviewed-on: https://go-review.googlesource.com/c/go/+/318249
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This test is also now flakey on this platform.
Updates #36435
Updates #42464
Change-Id: Idedb81478178ffffe7a9c125a6e8bbd83458f9ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/315794
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Convert the syscall package on openbsd/arm to use libc rather than performing
direct system calls.
Updates #36435
Change-Id: Iff3a91c959292cbf4e0a09c7fd34efc8e88ff83f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315793
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Use libc rather than performing direct system calls for the runtime on
openbsd/arm.
Updates #36435
Change-Id: If64a96a61c80b9748792f8a85a8f16ed6ebca91f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315792
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Switch openbsd/arm to locking via libc, rather than performing direct
system calls.
Update #36435
Change-Id: I190abb1aa544d2cb406fe412960ec106c9716f87
Reviewed-on: https://go-review.googlesource.com/c/go/+/315791
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
This switches openbsd/arm to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: Ia8749e3723a9967905c33b6d93dfd9be797a486c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315790
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Windows syscall functions (e.g. syscall.Syscall9) are defined as
cgo_unsafe_args (because it takes the address of one argument and
use that to access all arguments) which makes them ABI0. In some
case we may need ABI wrappers for them. Because those functions
have a large number of arguments, the wrapper can take a
non-trivial amount of stack frame, causing nosplit overflow when
inlining is disabled. The overflow call chain involves
deferreturn.
This CL changes a deferred call to unlockOSThread to a direct
call. If the syscall functions panics, it is likely a fatal error
anyway.
Fixes #45698.
Change-Id: I280be826644de1205f9c8f5efaa4ec5e1b4eebc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/316650
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I09a2be64e96fe85d84560728814af74b234d7210
GitHub-Last-Rev: bc881ea0022326fcc35e0356a79634fde00efd2a
GitHub-Pull-Request: golang/go#45929
Reviewed-on: https://go-review.googlesource.com/c/go/+/316409
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
|
|
Revive CL 310149
Change-Id: Ib4714ea5b2ade32c0f66edff841a79d8212bd79a
Reviewed-on: https://go-review.googlesource.com/c/go/+/313009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
|
|
The setg call a few lines earlier has already performed the same iscgo check
and called save_g if necessary.
Change-Id: I6e7c44cef4e0397d6001a3d5b7e334cdfbc3ce22
Reviewed-on: https://go-review.googlesource.com/c/go/+/316929
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Currently if a signal lands on a non-Go thread that's handled by the Go
handler, Go will emit a message. However, unlike everywhere else in the
runtime, Go will not abort the process after, and the signal handler
will try to continue executing.
This leads to cascading failures and possibly even memory corruption.
For #45638.
Change-Id: I546f4e82f339d555bed295528d819ac883b92bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/316809
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
In the event allocSpan returned a nil, this would crash.
Cleaned up the code and comments slightly, too.
Change-Id: I6231d4b4c14218e6956b4a97a205adc3206f59ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/316429
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
This edge can happen when forcegchelper() calls
goparkunlock(&forcegc.lock, ...) while holding the forcegc lock.
goparkunlock() eventually calls park_m(). In park_m(), traceGoPark()
(which leads to (*traceStackTable).put() and acquires the traceStackTab
lock) can be called before the forcegc lock is released.
Fixes #45774
Change-Id: If0fceab596712eb9ec0b9b47326778bc0ff80913
Reviewed-on: https://go-review.googlesource.com/c/go/+/316029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Carlos Amedee <carlos@golang.org>
|
|
Updates #19367.
Updates #40481.
Change-Id: Iabd2afdd0d520e5d68fd9e6dedd013335a4b3886
Reviewed-on: https://go-review.googlesource.com/c/go/+/312214
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Convert the syscall package on openbsd/386 to use libc rather than performing
direct system calls.
Updates #36435
Change-Id: Ifcfbca0e6b933762596a564243caa850dac01442
Reviewed-on: https://go-review.googlesource.com/c/go/+/287654
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Use libc rather than performing direct system calls for the runtime on
openbsd/386.
Updates #36435
Change-Id: I0cd65368bc824c81f5f98ea24e4f82db5468b170
Reviewed-on: https://go-review.googlesource.com/c/go/+/287653
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
If something "huge" is allocated, and the zeroing is trivial (no pointers
involved) then zero it by chunks in a loop so that preemption can occur,
not all in a single non-preemptible call.
Benchmarking suggests that 256K is the best chunk size.
Updates #42642.
Change-Id: I94015e467eaa098c59870e479d6d83bc88efbfb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/270943
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Include a NOP with the SP in order to disable/bypass vet asmdecl checks
for runtime.mstart_stub on openbsd/386. Without this we get:
runtime/sys_openbsd_386.s:33:1: [386] mstart_stub: use of 32(SP) points beyond argument frame
Change-Id: I834ae3dbceffcb5776481b076ec2afe3700671cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/315789
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
|
|
Switch openbsd/386 to locking via libc, rather than performing direct
system calls.
Update #36435
Change-Id: I8198171e21f9acf28846ad723ea9ff48f7c8a69d
Reviewed-on: https://go-review.googlesource.com/c/go/+/287652
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
This switches openbsd/386 to thread creation via pthreads, rather than doing
direct system calls.
Update #36435
Change-Id: I000a815fc0edd0272c3285954f3f007229bc60a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/250577
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Currently, for stack objects, the compiler emits metadata that
includes the offset and type descriptor for each object. The type
descriptor symbol has many fields, and it references many other
symbols, e.g. field/element types, equality functions, names.
Observe that what we actually need at runtime is only the GC
metadata that are needed to scan the object, and the GC metadata
are "leaf" symbols (which doesn't reference other symbols). Emit
only the GC data instead. This avoids bringing live the type
descriptor as well as things referenced by it (if it is not
otherwise live).
This reduces binary sizes:
old new
hello (println) 1187776 1133856 (-4.5%)
hello (fmt) 1902448 1844416 (-3.1%)
cmd/compile 22670432 22438576 (-1.0%)
cmd/link 6346272 6225408 (-1.9%)
No significant change in compiler speed.
name old time/op new time/op delta
Template 184ms ± 2% 186ms ± 5% ~ (p=0.905 n=9+10)
Unicode 78.4ms ± 5% 76.3ms ± 3% -2.60% (p=0.009 n=10+10)
GoTypes 1.09s ± 1% 1.08s ± 1% -0.73% (p=0.027 n=10+8)
Compiler 85.6ms ± 3% 84.6ms ± 4% ~ (p=0.143 n=10+10)
SSA 7.23s ± 1% 7.25s ± 1% ~ (p=0.780 n=10+9)
Flate 116ms ± 5% 115ms ± 6% ~ (p=0.912 n=10+10)
GoParser 201ms ± 4% 195ms ± 1% ~ (p=0.089 n=10+10)
Reflect 455ms ± 1% 458ms ± 2% ~ (p=0.050 n=9+9)
Tar 155ms ± 2% 155ms ± 3% ~ (p=0.436 n=10+10)
XML 202ms ± 2% 200ms ± 2% ~ (p=0.053 n=10+9)
Change-Id: I33a7f383d79afba1a482cac6da0cf5b7de9c0ec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/313514
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
This change adds four additional metrics to the runtime/metrics package
to fill in a few gaps with runtime.MemStats that were overlooked. The
biggest one is TotalAlloc, which is impossible to find with the
runtime/metrics package, but also add a few others for convenience and
clarity. For instance, the total number of objects allocated and freed
are technically available via allocs-by-size and frees-by-size, but it's
onerous to get them (one needs to sum the sample counts in the
histograms).
The four additional metrics are:
- /gc/heap/allocs:bytes -- total bytes allocated (TotalAlloc)
- /gc/heap/allocs:objects -- total objects allocated (Mallocs - [tiny])
- /gc/heap/frees:bytes -- total bytes frees (TotalAlloc-HeapAlloc)
- /gc/heap/frees:objects -- total objects freed (Frees - [tiny])
This change also updates the descriptions of allocs-by-size and
frees-by-size to be more precise.
Change-Id: Iec8c1797a584491e3484b198f2e7f325b68954a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312431
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Top align allocations in tinyalloc buckets when in race mode.
This will make checkptr checks more reliable, because any code
that modifies a pointer past the end of the object will trigger
a checkptr error.
No test, because we need -race for this to actually kick in. We could
add it to the race detector tests, but the race detector tests are all
geared towards race detector reports, not checkptr reports. Mucking
with parsing reports is more than a test is worth.
Fixes #38872
Change-Id: Ie56f0fbd1a9385539f6631fd1ac40c3de5600154
Reviewed-on: https://go-review.googlesource.com/c/go/+/315029
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
iOS arm64 is a 64-bit platform but with a strictly 32-bit address space
(technically 33 bits, but the bottom half is unavailable to the
application). Since address space is limited, use 4 MiB arenas instead
of 64 MiB arenas. No changes are needed to the arena index because it's
still relatively small; this change just brings iOS more in line with
32-bit platforms.
Change-Id: I484e2d273d896fd0a57cd5c25012df0aef160290
Reviewed-on: https://go-review.googlesource.com/c/go/+/270538
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
It's never called.
Change-Id: I8956743b21301816b5f37a9b34e3f50ef7b2e70a
Reviewed-on: https://go-review.googlesource.com/c/go/+/314771
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: Iec9de5ca56eb68d524bbaa0668515dbd09ad38a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/314770
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
There was only one meaningful caller, which changes to call time_now.
This clearly separates systems that use walltime1 to be just those
that use the stub version of time_now. That is to say, those that do
not provide an assembler version of time_now.
Change-Id: I14c06cc402070bd705f953af6f9966785015e2a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314769
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
name old time/op new time/op delta
AfterFunc-12 66.7µs ± 3% 66.8µs ± 4% ~ (p=0.836 n=20+20)
After-12 99.4µs ± 4% 98.1µs ± 3% -1.31% (p=0.013 n=20+20)
Stop-12 66.1µs ±12% 65.4µs ±10% ~ (p=0.602 n=20+20)
SimultaneousAfterFunc-12 110µs ± 1% 114µs ± 2% +3.98% (p=0.000 n=19+18)
StartStop-12 32.1µs ±15% 32.2µs ±13% ~ (p=0.620 n=20+20)
Reset-12 3.66µs ± 2% 3.63µs ± 5% -0.92% (p=0.018 n=20+17)
Sleep-12 134µs ± 1% 139µs ± 4% +3.97% (p=0.000 n=20+18)
Ticker-12 32.8µs ± 1% 32.6µs ± 2% -0.63% (p=0.017 n=18+20)
TickerReset-12 3.72µs ± 3% 3.71µs ± 3% ~ (p=0.753 n=20+20)
TickerResetNaive-12 68.9µs ±11% 65.8µs ± 8% -4.44% (p=0.008 n=20+20)
Now-12 33.3ns ± 1% 29.6ns ± 0% -11.06% (p=0.000 n=18+16)
NowUnixNano-12 34.6ns ± 0% 31.2ns ± 0% -9.94% (p=0.000 n=20+17)
NowUnixMilli-12 35.0ns ± 1% 30.9ns ± 0% -11.75% (p=0.000 n=19+15)
NowUnixMicro-12 35.0ns ± 0% 30.9ns ± 0% -11.85% (p=0.000 n=20+19)
Format-12 302ns ± 3% 306ns ± 3% +1.22% (p=0.009 n=20+20)
FormatNow-12 184ns ± 5% 187ns ± 2% +1.25% (p=0.046 n=20+19)
MarshalJSON-12 262ns ± 2% 270ns ± 3% +2.99% (p=0.000 n=20+20)
MarshalText-12 262ns ± 3% 268ns ± 3% +2.37% (p=0.000 n=19+19)
Parse-12 145ns ± 1% 148ns ± 0% +2.27% (p=0.000 n=18+19)
ParseDuration-12 82.3ns ± 1% 79.7ns ± 1% -3.06% (p=0.000 n=20+20)
Hour-12 4.48ns ± 1% 4.42ns ± 1% -1.32% (p=0.000 n=19+19)
Second-12 4.44ns ± 1% 4.42ns ± 1% -0.39% (p=0.000 n=20+18)
Year-12 11.2ns ± 1% 11.1ns ± 1% ~ (p=0.193 n=20+20)
Day-12 14.8ns ± 0% 14.8ns ± 1% ~ (p=0.873 n=19+20)
ISOWeek-12 17.2ns ± 0% 17.2ns ± 0% ~ (p=0.605 n=18+20)
name old avg-late-ns new avg-late-ns delta
ParallelTimerLatency-12 375k ± 3% 377k ± 3% ~ (p=0.445 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-12 136k ± 2% 137k ± 2% ~ (p=0.242 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-12 97.4k ±11% 96.4k ±10% ~ (p=0.336 n=19+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-12 74.8k ± 3% 74.2k ± 3% ~ (p=0.158 n=20+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-12 70.7k ± 7% 70.4k ± 6% ~ (p=0.879 n=20+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-12 65.8k ± 9% 66.3k ±14% ~ (p=0.594 n=17+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-12 55.5k ±29% 56.7k ±30% ~ (p=0.758 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-12 45.3k ±29% 43.6k ±33% ~ (p=0.212 n=19+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-12 64.7k ±46% 65.2k ±78% ~ (p=0.480 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-12 147k ±88% 119k ±83% ~ (p=0.092 n=19+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-12 2.63M ±29% 2.70M ±59% ~ (p=0.989 n=19+20)
StaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-12 81.4k ± 4% 80.2k ± 3% -1.55% (p=0.009 n=17+18)
name old max-late-ns new max-late-ns delta
ParallelTimerLatency-12 7.66M ±102% 6.98M ±131% ~ (p=0.445 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-12 381k ±12% 382k ±17% ~ (p=0.901 n=17+16)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-12 388k ±69% 356k ±10% ~ (p=0.363 n=17+16)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-12 350k ±17% 347k ±25% ~ (p=0.538 n=19+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-12 378k ±52% 341k ±30% ~ (p=0.153 n=18+17)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-12 392k ±54% 410k ±78% ~ (p=0.730 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-12 467k ±80% 527k ±129% ~ (p=0.616 n=17+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-12 915k ±138% 1023k ±227% ~ (p=0.696 n=20+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-12 1.84M ±155% 1.74M ±158% ~ (p=0.893 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-12 6.95M ±92% 7.66M ±91% ~ (p=0.687 n=19+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-12 18.6M ±22% 16.2M ±28% -12.78% (p=0.003 n=19+19)
StaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-12 1.01M ± 8% 1.04M ±10% ~ (p=0.111 n=19+18)
Change-Id: I96aa2e0206a6e9286bcbfc8be372e84608ed4e2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/314277
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Build other definitions with the !faketime build tag.
This makes it easy for us to add new assembly implementations of time.now.
Change-Id: I4e48e41a4a04ab001030e6d1cdd9cebfa0161b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314274
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
This is a step toward separating whether time.now is implemented in
assembly from whether we are using faketime.
Change-Id: I8bf059b44a103b034835e3d3b799319cc05e9552
Reviewed-on: https://go-review.googlesource.com/c/go/+/314273
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I1a583d3da9cca4ac51f3fec9b508b7638b452d60
Reviewed-on: https://go-review.googlesource.com/c/go/+/314270
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Add support for cgo on openbsd/mips64.
Fixes #43005
Change-Id: I2386204f53fa984a01a9d89f0b6c96455768f326
Reviewed-on: https://go-review.googlesource.com/c/go/+/275896
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Block profiles were biased towards infrequent long events over frequent
short events. This fix corrects the bias by aggregating shorter events
as longer but less frequent in the profiles. As a result their
cumulative duration will be accurately represented in the profile
without skewing their sample mean (duration/count).
Credit to @dvyukov for suggesting to adjust the count in the
saveblockevent function.
Fixes #44192.
Change-Id: I71a99d7f6ebdb2d484d44890a2517863cceb4004
Reviewed-on: https://go-review.googlesource.com/c/go/+/299991
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Currently tiny allocations are not represented in either MemStats or
runtime/metrics, but they're represented in MemStats (indirectly) via
Mallocs. Add them to runtime/metrics by first merging
memstats.tinyallocs into consistentHeapStats (just for simplicity; it's
monotonic so metrics would still be self-consistent if we just read it
atomically) and then adding /gc/heap/tiny/allocs:objects to the list of
supported metrics.
Change-Id: Ie478006ab942a3e877b4a79065ffa43569722f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312909
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
While debugging issue #45638, I discovered that some tests were using
--buildmode command line parameter instead of -buildmode.
The --buildmode parameter is handled properly by the flag package - it
is read as -buildmode. But we should correct code anyway.
Updates #45638
Change-Id: I75cf95c7d11dcdf4aeccf568b2dea77bd8942352
Reviewed-on: https://go-review.googlesource.com/c/go/+/313351
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.
While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.
TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.
Updates #45638
Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b
Reviewed-on: https://go-review.googlesource.com/c/go/+/313250
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I2770195cb53220948081a6265f891ef064e4f763
Reviewed-on: https://go-review.googlesource.com/c/go/+/313629
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Currently there's a minor bug where the constant for the min fraction of
time spent scavenging is rounded down to zero. I don't think this
affects anything in practice because this case is exceedingly rare and
extreme, but currently it doesn't properly prevent the pacing parameters
from getting out of hand in these extreme cases.
Fixes #44036.
Change-Id: I7de644ab0ecac33765c337a736482a0966882780
Reviewed-on: https://go-review.googlesource.com/c/go/+/313249
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.
This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.
Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.
Fixes #44610.
Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Our toolchain does not like -mnop-fun-dllimport.
Change-Id: Iaaee01fe0f4b0959406a35eb13aefa390116b483
Reviewed-on: https://go-review.googlesource.com/c/go/+/312043
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
