This change adds a benchmark to the runtime which measures ReadMemStats
latencies. It generates allocations with lots of pointers to keep the GC
busy while hitting ReadMemStats and measuring the time it takes to
complete.
Updates #19812.
Change-Id: I7a76aaf497ba5324d3c7a7b3df32461b3e6c3ac8
Reviewed-on: https://go-review.googlesource.com/c/go/+/220177
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Currently, dedicated background mark workers are essentially always
non-preemptible.
This change makes it so that dedicated background mark workers park if
their preemption flag is set and someone is trying to STW, allowing them
to do so.
This change prepares us for allowing a STW to happen (and happen
promptly) during GC marking in a follow-up change.
Updates #19812.
Change-Id: I67fb6085bf0f0aebd18ca500172767818a1f15e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/215157
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
* gitlab.com/yumeko/MumbleEmu: the go-import tag now points to
gitlab.com/yumeko/mumbleemu, but the module path hasn't changed
in go.mod.
* github.com/openshift/api: tag v3.9.0 was deleted.
* github.com/AlexStocks/log4go: tag v1.0.5 was deleted.
* github.com/belogik/goes: repository is no longer available.
* llvm.org/llvm: server times out and disconnects after 30-40 mins.
Also, fix a typo in an error message.
With these versions removed, zip_sum_test passes.
Updates #35290
Change-Id: Id3bdb8675a5582f88a6ff4c12dd7d1abe31aa56f
Reviewed-on: https://go-review.googlesource.com/c/go/+/218917
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Use that operator to make test_race_install_cgo agnostic to whether GOROOT/pkg is writable.
Updates #37573
Updates #30316
Change-Id: I018c63b3c369209345069f917bbb3a52179e2b58
Reviewed-on: https://go-review.googlesource.com/c/go/+/223746
Reviewed-by: Jay Conrod <jayconrod@google.com>
If multiple threads call preemptone to preempt the same M, it may
send many signals to the same M such that it hardly make
progress, causing live-lock problem. Only send a signal if there
isn't already one pending.
Fixes#37741.
Change-Id: Id94adb0b95acbd18b23abe637a8dcd81ab41b452
Reviewed-on: https://go-review.googlesource.com/c/go/+/223737
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The missing brace made the 'stale' command a no-op in the non-error case.
Fix the 'short' skip in install_cross_gobin (it was backward) and
update it to no longer check staleness of a not-necessarily-stale
target and to no longer expect to be able to install into GOROOT/pkg.
(This was missed in #30316 because that part of the test was
erroneously skipped in non-short mode.)
Change-Id: I6a276fec5fa5e5da3fe0daf0c2b5086116ed7c1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/223747
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Adds a new interface, driver.ConnectionValidator, to allow
drivers to signal they should not be used again,
separatly from the session resetter interface.
This is done now that the session reset is done
after the connection is put into the connection pool.
Previous behavior attempted to run Session Resets
in a background worker. This implementation had two
problems: untested performance gains for additional
complexity, and failures when the pool size
exceeded the connection reset channel buffer size.
Fixes#31480
Change-Id: I7d483b883c24a362c292471e87a88db5b204d1d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/174122
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The documentation for m.Run says it returns an "exit code" to pass to
os.Exit. The argument to os.Exit is named "code".
While "exit code", "exit status" and "exit status code" are all valid ways
to refer to the same concept, prefer to stick to one form for consistency
and to avoid confusing users.
Change-Id: If76ee3fab5cc99c79e05ac1a4e413790a9c93d60
GitHub-Last-Rev: 85a081d2f0
GitHub-Pull-Request: golang/go#37899
Reviewed-on: https://go-review.googlesource.com/c/go/+/223778
Reviewed-by: Gabriel Aszalos <gabriel.aszalos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Gabriel Aszalos <gabriel.aszalos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing test attempted to remove '_race' binaries from
GOROOT/pkg, which could not only fail if GOROOT is read-only, but also
interfere with other tests run in parallel.
Updates #30316
Updates #37573
Updates #17751
Change-Id: Id7e2286ab67f8333baf4d52244b7f4476aa93a46
Reviewed-on: https://go-review.googlesource.com/c/go/+/223745
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If TestMain reports a wrong exit code to os.Exit, the test will be
exited with exist code inconsist with test results.
This CL eliminates the requirement of calling os.Exit in TestMain.
Now, m.Run records the execution status of its test, the outer
main func will call os.Exit with that exit code if TestMain does
not call os.Exit.
If TestMain does not call m.Run, the outer main func remain calls
os.Exit(0) as before.
Fixes#34129
Change-Id: I9598023e03b0a6260f0217f34df41c231c7d6489
Reviewed-on: https://go-review.googlesource.com/c/go/+/219639
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In Go 1.13, when the network poller found a list of ready goroutines,
they were added to the global run queue. The timer goroutine would
typically sleep in a futex with a timeout, and when the timeout
expired the timer goroutine would either be handed off to an idle P
or added to the global run queue. The effect was that on a busy system
with no idle P's goroutines waiting for timeouts and goroutines waiting
for the network would start at the same priority.
That changed on tip with the new timer code. Now timer functions are
invoked directly from a P, and it happens that the functions used
by time.Sleep and time.After and time.Ticker add the newly ready
goroutines to the local run queue. When a P looks for work it will
prefer goroutines on the local run queue; in fact it will only
occasionally look at the global run queue, and even when it does it
will just pull one goroutine off. So on a busy system with both active
timers and active network connections the system can noticeably prefer
to run goroutines waiting for timers rather than goroutines waiting
for the network.
This CL undoes that change by, when possible, adding goroutines
waiting for the network to the local run queue of the P that checked.
This doesn't affect network poller checks done by sysmon, but it
does affect network poller checks done as each P enters the scheduler.
This CL also makes injecting a list into either the local or global run
queue more efficient, using bulk operations rather than individual ones.
Change-Id: I85a66ad74e4fc3b458256fb7ab395d06f0d2ffac
Reviewed-on: https://go-review.googlesource.com/c/go/+/216198
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Fixes#36987
Change-Id: I91ea1a42f75302de5256a22d382ab7f1b307a498
Reviewed-on: https://go-review.googlesource.com/c/go/+/217360
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also rewrite subtraction of zero to NEG/NEGW.
Change-Id: I216e286d1860055f2a07fe2f772cd50f366ea097
Reviewed-on: https://go-review.googlesource.com/c/go/+/221691
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Provide NEG/NEGW pseudo-instructions, which translate to SUB/SUBW with the
zero register as a source.
Change-Id: I2c1ec1e75611c234c5ee8e39390dd188f8e42bae
Reviewed-on: https://go-review.googlesource.com/c/go/+/221689
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add a NOT pseudo-instruction that translates to XORI $-1.
Change-Id: I2be4cfe2939e988cd7f8d30260b704701d78475f
Reviewed-on: https://go-review.googlesource.com/c/go/+/221688
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Use instructions in place of currently used defines.
Updates #36765
Change-Id: I00bb59e77b1aace549d7857cc9721ba2cb4ac6ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/220541
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add support for Load-Reserved (LR) and Store-Conditional (SC) instructions.
Use instructions in place of currently used defines.
Updates #36765
Change-Id: I77e660639802293ece40cfde4865ac237e3308d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/220540
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also remove #define's that were previously in use.
Updates #36765
Change-Id: I90b6a8629c78f549012f3f6c5f3b325336182712
Reviewed-on: https://go-review.googlesource.com/c/go/+/220539
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Rework instruction generation so that multiple instructions are generated
from a single obj.Prog, rather than the current approach where obj.Progs
are rewritten. This allows the original obj.Prog to remain intact, before
being converted into an architecture specific instruction form.
This simplifies the code and removes a level of indirection that results
from trying to manipulate obj.Prog.To/obj.Prog.From into forms that match
the instruction encoding. Furthermore, the errors reported make more sense
since it matches up with the actual assembly that was parsed.
Note that the CALL/JMP/JALR type sequences have not yet been migrated to
this framework and will likely be converted at a later time.
Updates #27532
Change-Id: I9fd12562ed1db0a08cfdc32793897d2a1920ebaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/211917
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Store the relocation offset and symbol in obj.Prog.RestArgs, rather than
overloading obj.Prog.From and having to deal with invalid offsets
potentially existing when the instruction is encoded.
Change-Id: Iff0d678361677e78b41b887f6eba08cee94fccb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/218197
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This removes the TODO leftover by replacing the original int32 for
atomicBool that mimicks atomic operations for boolean.
Change-Id: I1b2cac0c9573c890c7315e9906ce6bfccee3d770
Reviewed-on: https://go-review.googlesource.com/c/go/+/223357
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
s390x has inaccurate range reduction for the assembly routines
in math so these tests are diabled until these are corrected.
Updates #37854
Change-Id: I1e26acd6d09ae3e592a3dd90aec73a6844f5c6fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/223457
Run-TryBot: Brian Kessler <brian.m.kessler@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Tan has poles along the real axis. In order to accurately calculate
the value near these poles, a range reduction by Pi is performed and
the result calculated via a Taylor series. The prior implementation
of range reduction used Cody-Waite range reduction in three parts.
This fails when x is too large to accurately calculate the partial
products in the summation accurately. Above this threshold, Payne-Hanek
range reduction using a multiple precision value of 1/Pi is required.
Additionally, the threshold used in math/trig_reduce.go for Payne-Hanek
range reduction was not set conservatively enough. The prior threshold
ensured that catastrophic failure did not occur where the argument x
would not actually be reduced below Pi/4. However, errors in reduction
begin to occur at values much lower when z = ((x - y*PI4A) - y*PI4B) - y*PI4C
is not exact because y*PI4A cannot be exactly represented as a float64.
reduceThreshold is lowered to the proper value.
Fixes#31566
Change-Id: I0f39a4171a5be44f64305f18dc57f6c29f19dba7
Reviewed-on: https://go-review.googlesource.com/c/go/+/172838
Reviewed-by: Rob Pike <r@golang.org>
Many of tests in this package assumed reasonable scheduling latency.
Unfortunately, scheduling latency on builders and CI systems is not
always reasonable.
Rather than expecting that a timeout is detected within a fixed short
interval, we can use (*testing.T).Deadline to portably scale the time
we're willing to wait to something appropriate to the builder.
Some of the tests also included arbitrary-duration sleeps, which are
no longer needed after CL 196521; we can remove those instead of
extending them.
Promptness of timeouts is also an important property, but testing that
property is better suited to benchmarks than to tests proper: unlike
tests, we generally expect benchmarks to be run in a quiet,
low-contention environment.
Fixes#13956
Change-Id: I0797e2267fb778c8ad94add56d797de9e2c885e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/223019
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Instead, note that mlock has failed, start trying the mitigation of
touching the signal stack before sending a preemption signal, and,
if the program crashes, mention the possible problem and a wiki page
describing the issue (https://golang.org/wiki/LinuxKernelSignalVectorBug).
Tested on a kernel in the buggy version range, but with the patch,
by using `ulimit -l 0`.
Fixes#37436
Change-Id: I072aadb2101496dffd655e442fa5c367dad46ce8
Reviewed-on: https://go-review.googlesource.com/c/go/+/223121
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Previously, we suppressed a `to create a module there, run: … go mod
init' warning only if the config file itself (such as .git/config) was
found in GOROOT. However, our release tarballs don't include the
.git/config, so that case was not encountered, and the warning could
occur based on a config file found in some parent directory (outside
of GOROOT entirely).
Instead, skip the directory walk completely if the working directory
is anywhere in GOROOT.
Fixes#34191
Change-Id: I9f774901bfbb53b700407c4882f37d6339d023fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/223340
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Continue to simplify, rename for clarity,
improve docs, and reduce variable scope.
This is in preparation for this function becoming
more complicated.
Passes toolstash-check.
Updates #37608
Change-Id: I630a4e07c92297c46d18aea69ec29852d6371ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/222919
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
shortcircuitBlock contained a loop to handle blocks like
b: <- p q
v = Phi true false
If v -> t u
in a single execution.
This change makes shortcircuitBlock do it in two instead,
one for each constant phi arg.
Motivation: Upcoming changes will expand the range of
blocks that the shortcircuit pass can handle.
Those changes need to understand what the CFG
will look like after the rewrite in shortcircuitBlock.
Making shortcircuitBlock do only a single CFG
modification at a time significantly simplifies that code.
In theory, this is less efficient, but not measurably so.
There is minor, unimportant churn in the generated code.
Updates #37608
Change-Id: Ia6dce7011e3e19b546ed1e176bd407575a0ab837
Reviewed-on: https://go-review.googlesource.com/c/go/+/222918
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
v is pretty generic. Subsequent changes will make this function
more complicated, so rename it now, independently, for easier review.
v is the control value for the block (or its underlying phi);
call it ctl.
Passes toolstash-check.
Updates #37608
Change-Id: I3fbae3344f1c95aff0a69c1e4f61ef637a54774e
Reviewed-on: https://go-review.googlesource.com/c/go/+/222917
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This commit extends the -spectre flag to cmd/asm and adds
a new Spectre mitigation mode "ret", which enables the use
of retpolines.
Retpolines prevent speculation about the target of an indirect
jump or call and are described in more detail here:
https://support.google.com/faqs/answer/7625886
Change-Id: I4f2cb982fa94e44d91e49bd98974fd125619c93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/222661
Reviewed-by: Keith Randall <khr@golang.org>
This commit adds a new cmd/compile flag -spectre,
which accepts a comma-separated list of possible
Spectre mitigations to apply, or the empty string (none),
or "all". The only known mitigation right now is "index",
which uses conditional moves to ensure that x86-64 CPUs
do not speculate past index bounds checks.
Speculating past index bounds checks may be problematic
on systems running privileged servers that accept requests
from untrusted users who can execute their own programs
on the same machine. (And some more constraints that
make it even more unlikely in practice.)
The cases this protects against are analogous to the ones
Microsoft explains in the "Array out of bounds load/store feeding ..."
sections here:
https://docs.microsoft.com/en-us/cpp/security/developer-guidance-speculative-execution?view=vs-2019#array-out-of-bounds-load-feeding-an-indirect-branch
Change-Id: Ib7532d7e12466b17e04c4e2075c2a456dc98f610
Reviewed-on: https://go-review.googlesource.com/c/go/+/222660
Reviewed-by: Keith Randall <khr@golang.org>
Function declarations with blank ("_") names do not introduce a binding,
and therefore cannot be referenced or executed (in fact, they do not
make it into the final compiled binary at all). As such, counters
defined while annotating their bodies will always be zero.
These types of functions are commonly used to create compile-time
checks (e.g., stringer) which are not expected to be executed.
Skip over these functions when annotating a file, preventing the unused
counters from being generated and appearing as uncovered lines in
coverage reports.
Fixes#36264
Change-Id: I6b516cf43c430a6248d68d5f483a3902253fbdab
Reviewed-on: https://go-review.googlesource.com/c/go/+/223117
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This test requires subversion to run, but does not check to see if it's
available before running as it does for git.
Call testenv.MustHaveExecPath to check beforehand to allow the test to
be skipped if the svn binary does not exist.
Change-Id: I16ae104621b221fc6e96f6c7dcd71bf406caa0c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/223082
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This does some clean up of the ppc64 opcodes to remove names
from the opcode list that don't actually assemble. At one time
names were added to this list to represent opcode "classes" to
organize other opcodes that have the same set of operand
combinations. Since this is not documented, it is confusing as
to which opcodes can be used in an asm file and which can't, and
which opcodes should be supported in the disassembler. It is
clearer for the user if the list of Go opcodes are all opcodes
that can be assembled with names that match the ppc64 opcode
where possible.
I found this when trying to use Go opcode XXLAND in an asm file
which seems like it should map to ppc64 xxland but when used it
gets this error:
go tool asm test_xxland.s
asm: bad r/r, r/r/r or r/r/r/r opcode XXLAND
asm: assembly failed
This change removes the opcodes that are only used for opcode
"classes" and fixes the case statement where they are referenced.
This also fixes XXLAND and XXPERM which are opcodes that should
assemble to their corresponding ppc64 opcode but do not.
Change-Id: I52300db6b22f7f8b3dd3491c3f35a384b943352c
Reviewed-on: https://go-review.googlesource.com/c/go/+/223138
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The timerproc function has been removed.
Fixes#37774
Change-Id: Ice5e1d8fec91cd6ee7f032e0d21e8315a26bc6a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/222783
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Update error messages for pointer alignment checks and pointer
arithmetic checks so that each type of error has a unique error
message.
Fixes#37488
Change-Id: Ida2c2fa3f041a3307d665879a463f9e8f2c1fd03
Reviewed-on: https://go-review.googlesource.com/c/go/+/223037
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The cleantimers can run for a while in some unlikely cases.
If the GC is trying to preempt the G, it is forced to wait as the
G is holding timersLock. To avoid introducing a GC delay,
return from cleantimers if the G has a preemption request.
Fixes#37779
Change-Id: Id9a567f991e26668e2292eefc39e2edc56efa4e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/223122
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
//line bogo.go:9999999 will cause 'go tool objdump' to crash
unless bogo.go has that many lines. Guard the array index
and return innocuous values (nil, nil) from the file cache.
Fixes#36683
Change-Id: I4a9f8444dc611654d270cc876e8848dfd2f84770
Reviewed-on: https://go-review.googlesource.com/c/go/+/223081
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
