nao20010128nao [Sat, 21 Mar 2020 06:52:58 +0000 (06:52 +0000)]
syscall/js: make wasm_exec.js compatible with Webpack
In Webpack, require("fs") will always be empty. This behavior throws an error: "fs.writeSync is not function". It happens when you did "fmt.Println".
This PR avoids such problem and use polyfill in wasm_exec.js on Webpack.
Dan Scales [Wed, 11 Mar 2020 19:08:03 +0000 (12:08 -0700)]
cmd/go: define a build tag for any GOEXPERIMENT which is enabled.
For each experiment that has been enabled in the toolchain, define a build tag
with the same name (but prefixed by "goexperiment.") which can be used for
compiling alternative files for the experiment. This allows changes for the
experiment, like extra struct fields in the runtime, without affecting the base
non-experiment code at all.
I use this capability in my CL for static lock ranking
(https://go-review.googlesource.com/c/go/+/207619), so that static lock ranking
can be fully enabled as a GOEXPERIMENT, but there is no overhead in the runtime
when the experiment is not enabled.
I added a test in cmd/go/testdata/scripts to make sure the build tags are being
defined properly. In order to implement the test, I needed to provide environment
variable GOEXPSTRING to the test scripts (with its value set from
objabi.Expstring(), so that it can determine the experiments baked into the
toolchain.
I filed https://github.com/golang/go/issues/37937 to make a builder with
GOEXPERIMENT set to 'staticlockranking'. This builder will ensure another variant
of GOEXPERIMENT is being tested regularly for this change, as well as checking
static lock ranking in the runtime.
Change-Id: Ieb4b86107238febd105558c1e639d30cfe57ab5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/222925
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
This makes all modern public keys in the standard library implement a
common interface (below) that can be used by applications for better
type safety and allows for checking that public (and private keys via
Public()) are equivalent.
interface {
Equal(crypto.PublicKey) bool
}
Equality for ECDSA keys is complicated, we take a strict interpretation
that works for all secure applications (the ones not using the
unfortunate non-constant time CurveParams implementation) and fails
closed otherwise.
Tests in separate files to make them x_tests and avoid an import loop
with crypto/x509.
Giovanni Bajo [Mon, 23 Mar 2020 08:21:44 +0000 (09:21 +0100)]
cmd/compile: fold LEAQ with constant scale into LEA
Discovered this after rebasing CL196679 (use poset bounds in prove).
Some tests fail with that CL applied:
codegen/smallintiface.go:11: linux/amd64/: opcode not found: "^LEAQ\\truntime.staticuint64s\\+8\\(SB\\)"
codegen/smallintiface.go:16: linux/amd64/: opcode not found: "^LEAQ\\truntime.staticuint64s\\+2024\\(SB\\)"
codegen/smallintiface.go:21: linux/amd64/: opcode not found: "^LEAQ\\truntime.staticuint64s\\+24\\(SB\\)"
The only difference in prove SSA dumps is that a single Lsh64x64
op with constant shift (<< 3) is marked as bounded. This triggers
a different rule matching sequence in lower, which manages to generate
worse code for the above testcases.
This CL fixes the above test after CL196679 is applied. Right now,
these rules never trigger (this CL passes toolstash -cmp), so I can't
write a test.
Change-Id: I353f1c79c1875cac1da82cd8afa1e05e42684f1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/224877
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Roland Shoemaker [Fri, 20 Mar 2020 20:28:43 +0000 (20:28 +0000)]
crypto/x509: add RevocationList and CreateRevocationList
The existing Certificate.CreateCRL method generates non-conformant CRLs and
as such cannot be used for implementations that require standards
compliance. This change implements a new top level method, CreateCRL, which
generates compliant CRLs, and offers an extensible API if any
extensions/fields need to be supported in the future.
Here is an example Issuer/CRL generated using this change:
-----BEGIN CERTIFICATE-----
MIIBNjCB3aADAgECAgEWMAoGCCqGSM49BAMCMBIxEDAOBgNVBAMTB3Rlc3Rpbmcw
IhgPMDAwMTAxMDEwMDAwMDBaGA8wMDAxMDEwMTAwMDAwMFowEjEQMA4GA1UEAxMH
dGVzdGluZzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABLHrudbSM36sn1VBrmm/
OfQTyEsI4tIUV1VmneOKHL9ENBGCiec4GhQm2SGnDT/sZy2bB3c3yozh/roS6cZJ
UZqjIDAeMA4GA1UdDwEB/wQEAwIBAjAMBgNVHQ4EBQQDAQIDMAoGCCqGSM49BAMC
A0gAMEUCIQCoAYN6CGZPgd5Sw5a1rd5VexciT5MCxTfXj+ZfJNfoiAIgQVCTB8AE
Nm2xset7+HOgtQYlKNw/rGd8cFcv5Y9aUzo=
-----END CERTIFICATE-----
-----BEGIN X509 CRL-----
MIHWMH0CAQEwCgYIKoZIzj0EAwIwEjEQMA4GA1UEAxMHdGVzdGluZxgPMDAwMTAx
MDIwMDAwMDBaGA8wMDAxMDEwMzAwMDAwMFowFjAUAgECGA8wMDAxMDEwMTAxMDAw
MFqgHjAcMA4GA1UdIwQHMAWAAwECAzAKBgNVHRQEAwIBBTAKBggqhkjOPQQDAgNJ
ADBGAiEAjqfj/IG4ys5WkjrbTNpDbr+saHGO/NujLJotlLL9KzgCIQDm8VZPzj0f
NYEQgAW4nsiUzlvEUCoHMw0141VCZXv67A==
-----END X509 CRL-----
Michael Anthony Knyszek [Mon, 27 Jan 2020 20:41:38 +0000 (20:41 +0000)]
runtime: use OnesCount64 to count allocated objects in a span
This change modifies the implementation of (*mspan).countAlloc by
using OnesCount64 (which on many systems is intrinsified). It does so by
using an unsafe pointer cast, but in this case we don't care about
endianness because we're just counting bits set.
This change means we no longer need the popcnt table which was redundant
in the runtime anyway. We can also simplify the logic here significantly
by observing that mark bits allocations are always 8-byte aligned, so we
don't need to handle any edge-cases due to the fact that OnesCount64
operates on 64 bits at a time: all irrelevant bits will be zero.
Overall, this implementation is significantly faster than the old one on
amd64, and should be similarly faster (or better!) on other systems
which support the intrinsic. On systems which do not, it should be
roughly the same performance because OnesCount64 is implemented using a
table in the general case.
Michael Anthony Knyszek [Wed, 18 Mar 2020 18:46:04 +0000 (18:46 +0000)]
runtime: add countAlloc benchmark
This change adds a small microbenchmark for (*mspan).countAlloc, which
we're about to replace. Admittedly this isn't a critical piece of code,
but the benchmark was useful in understanding the performance change.
Michael Anthony Knyszek [Fri, 20 Mar 2020 19:08:13 +0000 (19:08 +0000)]
cmd/compile: panic if trying to alias an intrinsic with no definitions
Currently if we try to alias an intrinsic which hasn't been defined for
any architecture (such as by accidentally creating the alias before the
intrinsic is created with addF), then we'll just silently not apply any
intrinsics to those aliases.
Catch this particular case by panicking in alias if we try to apply the
alias and it did nothing.
Change-Id: I98e75fc3f7206b08fc9267cedb8db3e109ec4f5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/224637
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Michael Anthony Knyszek [Fri, 20 Mar 2020 15:26:46 +0000 (15:26 +0000)]
cmd/compile: declare runtime bit func aliases after math/bits intrinsics
Currently runtime/internal/sys bit-manipulation functions are aliased to
math/bits functions, which are intrinsified. Unfortunately these aliases
are declared before the intrinsified versions are generated, resulting
in the generic version of the code being copied over.
This change moves the aliases for bit operations in runtime/internal/sys
after the addF calls to generate those intrinsics in SSA, so that the
intrinsified SSA representation of those functions actually get copied
over.
This should improve the overall performance of the runtime (especially
the page allocator) since these bit operations will actually be
intrinsified now.
Matthew Dempsky [Thu, 12 Mar 2020 19:14:02 +0000 (12:14 -0700)]
cmd/compile: skip generating args_stackmap for "pulled" funcs
In golang.org/cl/171464, we cleaned up generation of .stkobj linker
symbols, but we couldn't figure out why a similar cleanup to
.args_stackmap linker symbols caused problems.
The issue is that we only need/want to generate .args_stackmap for
functions that are implemented in assembly in the same package. When
"pulling" a function from another package via //go:linkname, we can
safely skip emitting .args_stackmap, because compiling that package
will have generated it, if necessary.
Fixes #31615.
Change-Id: If8680aa7dd5b4e8f268b6b032d746f1b8536c867
Reviewed-on: https://go-review.googlesource.com/c/go/+/223238
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
Andy Pan [Sun, 22 Mar 2020 06:22:41 +0000 (06:22 +0000)]
runtime: correct the system-call name of kevent in comment
Change-Id: Ib1f4a6f7e36d28eff39f597df5c4703bf62654a4
GitHub-Last-Rev: 15ea1b9fa846737bd5d30b7b98d8933f9992e5c7
GitHub-Pull-Request: golang/go#37994
Reviewed-on: https://go-review.googlesource.com/c/go/+/224590
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ben Schwartz [Mon, 10 Jun 2019 16:29:23 +0000 (12:29 -0400)]
runtime: speed up receive on empty closed channel
Currently, nonblocking receive on an open channel is about
700 times faster than nonblocking receive on a closed channel.
This change makes closed channels equally fast.
Fixes #32529. Includes a correction based on #36714.
Giovanni Bajo [Sun, 22 Mar 2020 08:28:21 +0000 (09:28 +0100)]
build: force all Windows batch files to CRLF
Batch files should use CRLF endings. LF endings mostly
work but in some situations they cause random errors like
goto commands failing for mysterious reasons. See
golang.org/issue/37791 for more information.
Next CL triggered one of such bug (a label was not being
recognized), so prepare for it by converting to CRLF.
This CL also touches all existing batch files to force git
to update the line endings (unfortunately, changing
.gitattributes only has effect next time the file is checked
out or modified).
Fixes #37791
Updates #9281
Change-Id: I6f9a114351cb7ac9881914400aa210c930eb8cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/96495
Run-TryBot: Giovanni Bajo <rasky@develer.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Alex Brainman [Sun, 16 Feb 2020 01:01:02 +0000 (12:01 +1100)]
runtime: ignore error returned by PowerRegisterSuspendResumeNotification
It appears that PowerRegisterSuspendResumeNotification is not supported
when running inside Docker - see issues #35447, #36557 and #37149.
Our current code relies on error number to determine Docker environment.
But we already saw PowerRegisterSuspendResumeNotification return
ERROR_FILE_NOT_FOUND, ERROR_INVALID_PARAMETERS and ERROR_ACCESS_DENIED
(see issues above). So this approach is not sustainable.
Just ignore PowerRegisterSuspendResumeNotification returned error.
Fixes #37149
Change-Id: I2beba9d45cdb8c1efac5e974e747827a6261915a
Reviewed-on: https://go-review.googlesource.com/c/go/+/219657
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Austin Clements [Fri, 20 Mar 2020 15:37:54 +0000 (11:37 -0400)]
runtime: use divRoundUp
There are a handful of places where the runtime wants to round up the
result of a division. We just introduced a helper to do this. This CL
replaces all of the hand-coded round-ups (that I could find) with this
helper.
Austin Clements [Wed, 26 Feb 2020 20:12:33 +0000 (15:12 -0500)]
runtime: fix rounding in materializeGCProg
materializeGCProg allocates a temporary buffer for unrolling a GC
program. Unfortunately, when computing the size of the buffer, it
rounds *down* the number of bytes needed to store bitmap before
rounding up the number of pages needed to store those bytes. The fact
that it rounds up to pages usually mitigates the rounding down, but
the type from #37470 exists right on the boundary where this doesn't
work:
On 64-bit, this GC bitmap is exactly 8 KiB of zeros, followed by three
one bits. Hence, this needs 8193 bytes of storage, but the current
math in materializeGCProg rounds *down* the three one bits to 8192
bytes. Since this is exactly pageSize, the next step of rounding up to
the page size doesn't mitigate this error, and materializeGCProg
allocates a buffer that is one byte too small. runGCProg then writes
one byte past the end of this buffer, causing either a segfault (if
you're lucky!) or memory corruption.
Ian Lance Taylor [Thu, 23 Jan 2020 23:02:43 +0000 (15:02 -0800)]
runtime/race: test that close synchronizes with read
Add a test to ensure that the race detector sees that closing a
channel synchronizes with a read from that channel.
This test case failed when CL 181543 was in the tree.
CL 181543 was reverted in CL 216158; this adds a test to make
sure that we don't re-introduce the problem at a later date.
For #32529
For #36714
Change-Id: I5a40f744c67c3f8191d6ad822710c180880a7375
Reviewed-on: https://go-review.googlesource.com/c/go/+/216099
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Ian Lance Taylor [Thu, 19 Mar 2020 21:29:23 +0000 (14:29 -0700)]
net: merge common Unix/Windows methods
When we added the internal/poll package, the Unix and Windows implementations
of several netFD methods became exactly the same, except for using a
different name for the string passed to wrapSyscallError.
One case is not an exact duplicate: we slightly tweak the implementation
of (*netFD).shutdown on Windows to wrap the error.
Change-Id: I3d87a317d5468ff8f1958d86f6189ea1ba697e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/224140
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Tobias Klauser [Thu, 19 Mar 2020 21:33:40 +0000 (22:33 +0100)]
crypto/x509: bump minimum macOS version to 10.11
The minimum macOS supported version is 10.11 as of Go 1.14, see #23011.
Thus, bump macosx-version-min to 10.11
While at it, drop __MAC_OS_X_VERSION_MAX_ALLOWED as suggested by
Filippo:
In general, I can see why we'd want to tell the libraries which
minimum version we target so they drop compatibility with older
versions. No idea why we'd specify a max version, unless it's to make
sure we don't use APIs added after that version, but then it would
have to be 1011 not 1015.
Let's try dropping that define and see if anything blows up? ¯\_(ツ)_/¯
Changkun Ou [Fri, 28 Feb 2020 20:53:38 +0000 (21:53 +0100)]
testing: fix data race between parallel subtests
This CL fixes a race condition if there are two subtests, and
one finishing but the other is panicking.
Fixes #37551
Change-Id: Ic33963eb338aec228964b95f7c34a0d207b91e00
Reviewed-on: https://go-review.googlesource.com/c/go/+/221322
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tim Möhlmann [Fri, 10 Jan 2020 10:06:53 +0000 (12:06 +0200)]
database/sql: add method Err on sql.Row
The Row.Err method is intended to assist wrapping sql.DB.
Because sql.Row is a struct with private fields,
a wrapper in an existing code base cannot easily provide users
with a different implementation without large rewrites.
Adding this method allows query level errors to be handled
centrally.
Fixes #35804
Change-Id: I94e6329de89a7ee1284ce9ef76af4363d2d081f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/214317 Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Kyle Nusbaum [Wed, 18 Mar 2020 19:17:50 +0000 (19:17 +0000)]
context: prevent creation of invalid contexts
This commit makes it impossible to create derived contexts with nil parents.
Previously it was possible to create derived contexts with nil parents, and
invalid contexts could propogate through the program. Eventually this can
cause a panic downstream, which is difficult to trace back to the source
of the error.
Although `WithCancel` and `WithDeadline` already panic if `parent` is `nil`, this adds explicit checks to give a useful message in the panic.
Fixes #37908
Change-Id: I70fd01f6539c1b0da0e775fc5457e32e7075e52c
GitHub-Last-Rev: 1b7dadd7db9ba42952644ad5e9a49591d6a5191f
GitHub-Pull-Request: golang/go#37898
Reviewed-on: https://go-review.googlesource.com/c/go/+/223777
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Anthony Knyszek [Mon, 17 Jun 2019 19:03:09 +0000 (19:03 +0000)]
runtime: don't hold worldsema across mark phase
This change makes it so that worldsema isn't held across the mark phase.
This means that various operations like ReadMemStats may now stop the
world during the mark phase, reducing latency on such operations.
Only three such operations are still no longer allowed to occur during
marking: GOMAXPROCS, StartTrace, and StopTrace.
For the former it's because any change to GOMAXPROCS impacts GC mark
background worker scheduling and the details there are tricky.
For the latter two it's because tracing needs to observe consistent GC
start and GC end events, and if StartTrace or StopTrace may stop the
world during marking, then it's possible for it to see a GC end event
without a start or GC start event without an end, respectively.
To ensure that GOMAXPROCS and StartTrace/StopTrace cannot proceed until
marking is complete, the runtime now holds a new semaphore, gcsema,
across the mark phase just like it used to with worldsema.
This change is being landed once more after being reverted in the Go
1.14 release cycle, since CL 215157 allows it to have a positive
effect on system performance.
For the benchmark BenchmarkReadMemStatsLatency in the runtime, which
measures ReadMemStats latencies while the GC is exercised, the tail of
these latencies reduced dramatically on an 8-core machine:
name old 50%tile-ns new 50%tile-ns delta
ReadMemStatsLatency-8 4.40M ±74% 0.12M ± 2% -97.35% (p=0.008 n=5+5)
name old 90%tile-ns new 90%tile-ns delta
ReadMemStatsLatency-8 102M ± 6% 0M ±14% -99.79% (p=0.008 n=5+5)
name old 99%tile-ns new 99%tile-ns delta
ReadMemStatsLatency-8 147M ±18% 4M ±57% -97.43% (p=0.008 n=5+5)
Michael Anthony Knyszek [Wed, 19 Feb 2020 20:54:25 +0000 (20:54 +0000)]
runtime: add ReadMemStats latency benchmark
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.
Michael Anthony Knyszek [Thu, 16 Jan 2020 21:39:42 +0000 (21:39 +0000)]
runtime: preempt dedicated background mark workers for STW
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.
Jay Conrod [Mon, 10 Feb 2020 19:42:02 +0000 (14:42 -0500)]
cmd/go/internal/modfetch/zip_sum_test: remove dead versions
* 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>
Cherry Zhang [Tue, 17 Mar 2020 00:08:00 +0000 (20:08 -0400)]
runtime: don't send preemption signal if there is a signal pending
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.
Bryan C. Mills [Tue, 17 Mar 2020 19:17:22 +0000 (15:17 -0400)]
cmd/go: add a missing curly-brace in the 'stale' command format string
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>
Daniel Theophanes [Fri, 26 Apr 2019 21:45:46 +0000 (14:45 -0700)]
database/sql: process all Session Resets synchronously
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.
Rodolfo Carvalho [Tue, 17 Mar 2020 10:41:45 +0000 (10:41 +0000)]
testing: use "exit code" in documentation consistently
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: 85a081d2f03c2cf9e8e519916986c59c86aebf57
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>
Bryan C. Mills [Tue, 17 Mar 2020 14:50:40 +0000 (10:50 -0400)]
cmd/go: replace TestCgoDependsOnSyscall with a simpler script test
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>
Changkun Ou [Sun, 16 Feb 2020 13:42:29 +0000 (14:42 +0100)]
testing: do not require os.Exit in TestMain
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>
Ian Lance Taylor [Fri, 24 Jan 2020 04:38:20 +0000 (20:38 -0800)]
runtime: add goroutines returned by poller to local run queue
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>
Paschalis Tsilias [Mon, 3 Feb 2020 08:47:41 +0000 (10:47 +0200)]
time: fix time.Before to reuse t.sec(), u.sec()
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>
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.
Joel Sing [Wed, 5 Feb 2020 17:47:52 +0000 (04:47 +1100)]
cmd/internal/obj/riscv: store relocation details in obj.Prog.RestArgs
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.
Robert Kuska [Fri, 13 Mar 2020 18:21:19 +0000 (19:21 +0100)]
net/http: use atomicBool for inShutdown
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>
Brian Kessler [Fri, 12 Apr 2019 04:54:18 +0000 (22:54 -0600)]
math/cmplx: implement Payne-Hanek range reduction
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>
Bryan C. Mills [Wed, 11 Mar 2020 19:14:38 +0000 (15:14 -0400)]
context: deflake time-sensitive tests
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>
Ian Lance Taylor [Thu, 12 Mar 2020 04:51:09 +0000 (21:51 -0700)]
runtime: don't crash on mlock failure
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>
Bryan C. Mills [Fri, 13 Mar 2020 16:51:09 +0000 (12:51 -0400)]
cmd/go/internal/modload: suppress the 'go mod init' hint for GOROOT more aggressively
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>
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.
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>
Russ Cox [Mon, 6 Jan 2020 15:31:39 +0000 (10:31 -0500)]
cmd/compile: add spectre mitigation mode enabled by -spectre
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>
zikaeroh [Thu, 12 Mar 2020 00:02:50 +0000 (17:02 -0700)]
cmd/cover: skip function declarations with blank names
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>
Lynn Boger [Tue, 10 Mar 2020 14:08:02 +0000 (10:08 -0400)]
cmd/internal/obj/ppc64: clean up some opcodes
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.