This new logic more closely mimics what we did before my CL stack.
I had reasoned that certainly
ts.adjust(now, force=true)
ts.run(now)
would be faster than
ts.adjust(now, force=false)
ts.run(now)
ts.adjust(now, force=true)
But certainty is just an emotion, and that turns out not to be the case.
I don't really understand why the second sequence is faster,
but it definitely is, so put it back.
goos: linux
goarch: amd64
pkg: time
cpu: AMD Ryzen 9 7950X 16-Core Processor
│ s7base.txt │ s7.txt │
│ sec/op │ sec/op vs base │
AdjustTimers10000-32 263.3µ ± 4% 239.9µ ± 5% -8.87% (p=0.000 n=10)
AdjustTimers10000SingleThread-32 1.742m ± 3% 1.686m ± 8% ~ (p=0.105 n=10)
AdjustTimers10000NoReset-32 192.2µ ± 2% 194.1µ ± 1% +1.00% (p=0.009 n=10)
AdjustTimers10000NoSleep-32 237.0µ ± 2% 226.2µ ± 3% -4.55% (p=0.001 n=10)
AdjustTimers10000NoResetNoSleep-32 185.2µ ± 1% 182.9µ ± 1% -1.23% (p=0.003 n=10)
goos: darwin
goarch: arm64
pkg: time
cpu: Apple M3 Pro
│ m3base.txt │ m3.txt │
│ sec/op │ sec/op vs base │
AdjustTimers10000-12 272.6µ ± 3% 269.3µ ± 2% ~ (p=0.063 n=10)
AdjustTimers10000SingleThread-12 1.126m ± 1% 1.176m ± 1% +4.42% (p=0.000 n=10)
AdjustTimers10000NoReset-12 255.1µ ± 2% 262.6µ ± 2% +2.96% (p=0.000 n=10)
AdjustTimers10000NoSleep-12 250.2µ ± 2% 247.8µ ± 1% ~ (p=0.063 n=10)
AdjustTimers10000NoResetNoSleep-12 230.3µ ± 1% 231.0µ ± 1% ~ (p=0.280 n=10)
Change-Id: I67b5765f97dfca0142ee38e15a9904b520f51e83
Reviewed-on: https://go-review.googlesource.com/c/go/+/574740
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The new code does not need a for-loop and is easier to read.
Change-Id: Ic182d63c4779c2179b721fcfaec362681284cc16
GitHub-Last-Rev: b3ee265df7
GitHub-Pull-Request: golang/go#63879
Reviewed-on: https://go-review.googlesource.com/c/go/+/538721
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
sysctl machdep.cpu.brand_string seems to be standard
across the BSDs. There does not seem to be a standard
way to get the CPU frequency.
Change-Id: Ic986d6c81dd54e1b84544317f2a53ce16801319b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520636
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
All of these maps and slices are made up of comparable types,
so we can avoid the overhead of reflection entirely.
Change-Id: If77dbe648a336ba729c171e84c9ff3f7e160297d
Reviewed-on: https://go-review.googlesource.com/c/go/+/574597
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This helps reduce confusion with cmd/internal/pgo, which performs
compilation-independent analysis. pgoir associates that data with the
IR from the current package compilation.
For #58102.
Change-Id: I9ef1c8bc41db466d3340f41f6d071b95c09566de
Reviewed-on: https://go-review.googlesource.com/c/go/+/569338
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The processing performed in cmd/preprofile is a simple version of the
same initial processing performed by cmd/compile/internal/pgo. Refactor
this processing into the new IR-independent cmd/internal/pgo package.
Now cmd/preprofile and cmd/compile run the same code for initial
processing of a pprof profile, guaranteeing that they always stay in
sync.
Since it is now trivial, this CL makes one change to the serialization
format: the entries are ordered by weight. This allows us to avoid
sorting ByWeight on deserialization.
Impact on PGO parsing when compiling cmd/compile with PGO:
* Without preprocessing: PGO parsing ~13.7% of CPU time
* With preprocessing (unsorted): ~2.9% of CPU time (sorting ~1.7%)
* With preprocessing (sorted): ~1.3% of CPU time
The remaining 1.3% of CPU time approximately breaks down as:
* ~0.5% parsing the preprocessed profile
* ~0.7% building weighted IR call graph
* ~0.5% walking function IR to find direct calls
* ~0.2% performing lookups for indirect calls targets
For #58102.
Change-Id: Iaba425ea30b063ca195fb2f7b29342961c8a64c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/569337
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On Windows, File.readdir currently fails if the volume information
can't be retrieved via GetVolumeInformationByHandle and if the
directory path is relative and can't be converted to an absolute
path.
This change makes readdir more robust by not failing in these cases,
as these steps are just necessary to support a potential call to
os.SameFile, but not for the actual readdir operation. os.SameFile
will still fail in these cases, but that's a separate issue tracked
in #62042.
Change-Id: I8d98d8379bdac4b2832fa433432a5f027756abaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/574155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For https://gcc.gnu.org/PR114453
Change-Id: If41d9fca6288b18ed47b0f21ff224c74ddb34958
Reviewed-on: https://go-review.googlesource.com/c/go/+/574536
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I1df0685c75fc1044ba46003a69ecc7dfc53bbc2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/574675
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This check serves only to provide a more descriptive error if the output
directory doesn't exist. That isn't useless, but I don't see why this tool
specifically should do this when no other part of the toolchain does.
For #58102.
Change-Id: I01cf9db2cc1dad85c3afd8a6b008c53f26cb877a
Reviewed-on: https://go-review.googlesource.com/c/go/+/569336
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This CL adjusts error handling to be a bit more idiomatic. The
processing function returns errors, leaving main to log and exit on
error.
This CL contains no functional changes.
For #58102.
Change-Id: I9074127cc675e177d046474b7f01fbc37d0bd4c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/569335
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In setupRSA we use named returns so that we can defer freeing of the
boring private key and context, but were using returns of the form
`return nil, nil, ...` which nil'd the named returns, preventing them
from actually being freed.
Update all of the returns to not shadow the named variables.
Thanks to Quim Muntal of Microsoft for reporting this issue.
Change-Id: Iaf0f0b17e123a7df730cb1e91a324fe622611f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/574195
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Might help with OOMs on 32-bit platforms
Change-Id: Idd5129c61ecdfeedd5a9a18fce85dbba27cab946
Reviewed-on: https://go-review.googlesource.com/c/go/+/574475
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 561080 introduced some failures for CBC and GCM crypto tests that are run during a build resulting in dashboard failures.
Tests that are failing:
- TestCBCEncrypterAES
- TestCBCDecrypterAES
- TestAESGCM
- TestGCMCounterWrap
- TestGCMAsm
This fixes those failures.
Change-Id: I90d6f8d279a3051cf951a1a9628afb8d0b5c2f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/574076
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Partial typo corrections, following https://go.dev/wiki/Spelling
Change-Id: I2357906ff2ea04305c6357418e4e9556e20375d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/573776
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Use the slices package and the built-in max to simplify the code.
There's no noticeable performance change in this modification.
Change-Id: I96e46ba8ab1323f1ba0b8c9b827836e217772cf2
GitHub-Last-Rev: f0111ac7e2
GitHub-Pull-Request: golang/go#66511
Reviewed-on: https://go-review.googlesource.com/c/go/+/573978
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Use a list + sorting instead of a map to keep track of collisions.
Should save a fair amount of memory.
Change-Id: I7b48cdb5f7060d12ebbb950d56b5c479f131c027
Reviewed-on: https://go-review.googlesource.com/c/go/+/574275
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Keith Randall <khr@google.com>
For Clone, Grow, Clip, Concat, Contains, Repeat.
Fixes#66435
Change-Id: Ife8f61427e9cd18b7106c100de8f82f9d7840c9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/573255
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Callers who invoke `*http.Client.Do` with a nil *Client will now panic
at the top of c.Do, instead of panicking when `deadline` attempts to
read `c.Timeout`.
Errors inside of net/http can be difficult to track down because the
caller is often invoking the standard library code via an SDK. This
can mean that there are many places to check when code panics, and
raises the importance of being clear about error messages.
If nil receiver calls panic during the `deadline()` call, callers
may confuse the error with a more common timeout or deadline
misconfiguration, which may lead a caller who passed a nil receiver
(the author, for example) down the wrong rabbit hole, or cause them to
suspect their timeout/deadline logic. It is less common to configure
client.Jar, so the probability of detecting the actual problem, given
the underlying error cause, is higher.
Fixes#53521.
Change-Id: If102d17bed56fdd950da6e87762166fd29724654
Reviewed-on: https://go-review.googlesource.com/c/go/+/413975
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Windows syscall.SyscallN currently calls lockOSThread for every syscall.
This can be expensive and produce unnecessary context switches,
especially when the syscall is called frequently under high contention.
The lockOSThread was necessary to ensure that cgocall wouldn't
reschedule the goroutine to a different M, as the syscall return values
are reported back in the M struct.
This CL instructs cgocall to copy the syscall return values into the
the M that will see the caller on return, so the caller no longer needs
to call lockOSThread.
Updates #58336.
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64,gotip-windows-amd64-longtest
Change-Id: If6644fd111dbacab74e7dcee2afa18ca146735da
Reviewed-on: https://go-review.googlesource.com/c/go/+/562915
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Follow up CL 560155
Change-Id: Id9230d79c296452f3741123c75b45c3d3b1be4f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/574295
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
There was recently a failure that we don't have a trace dump for because
the reader was passed Go122 but traces have moved onto version Go123.
Use version.Current to prevent this from happening again in the future.
Change-Id: I4f8b3c3ea5bad61a07839a697cd5d7793d62ea52
Reviewed-on: https://go-review.googlesource.com/c/go/+/574216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
base.ExitIfErrors() has been deferred at the begin of the function,
no need to call it again.
Change-Id: I4fc81572cfce0f84832448da667c65bb477dea22
GitHub-Last-Rev: cc15635875
GitHub-Pull-Request: golang/go#66392
Reviewed-on: https://go-review.googlesource.com/c/go/+/572576
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Replace some "reflect.DeepEqual" calls in the tests with
"slices.Equal" which is much faster for slice comparisons.
Remove unnecessary "runeSlice" and redundant helper functions.
Change-Id: Ib5dc41848d7a3c5149f41701d60471a487cff476
GitHub-Last-Rev: 87b5ed043d
GitHub-Pull-Request: golang/go#66509
Reviewed-on: https://go-review.googlesource.com/c/go/+/573977
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I0f67801ef2d3af65c39a27b8db6ebaa769ff7f92
GitHub-Last-Rev: feb7f79ea5
GitHub-Pull-Request: golang/go#66508
Reviewed-on: https://go-review.googlesource.com/c/go/+/574075
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We can reuse the buffer pool more aggressively when reading a directory
by returning the buffer to the pool as soon as we get to the end of the
directory, rather than waiting until the the os.File is closed.
This yields a significant memory usage reduction when traversing
nested directories recursively via os.File#ReadDir (and friends),
as the file pointers tends to be closed only after the entire
traversal is done. For example, this pattern is used in os.RemoveAll.
These are the improvements observed in BenchmarkRemoveAll:
goos: linux
goarch: amd64
pkg: os
cpu: AMD EPYC 7763 64-Core Processor
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
RemoveAll-4 3.847m ± 2% 3.823m ± 1% ~ (p=0.143 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
RemoveAll-4 39.77Ki ± 2% 17.63Ki ± 1% -55.68% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
RemoveAll-4 510.0 ± 0% 503.0 ± 0% -1.37% (p=0.000 n=10)
Change-Id: I70e1037378a02f1d670ccb7b275ee55f0caa6d0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/573358
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
We log TLS handshake errors in general, but currently do not log errors
when the first TLS record looks like an attempt to send HTTP to an HTTPS
port. There doesn't seem to be any principled reason to log the one and
not the other, so just log all TLS handshake errors.
Fixes#66501
Change-Id: I5d78a754d054c220be935513448515721fa387a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/573979
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Plain string concatenation with the plus operator for Attr.String is
much faster than invoking fmt.Sprintf. Added a benchmark to verify
this (just running on my Mac with stuff in the background but should
be sufficient to demonstrate the effect).
name old time/op new time/op delta
AttrString-8 1.24µs ± 3% 0.43µs ± 0% -65.17% (p=0.000 n=20+17)
name old alloc/op new alloc/op delta
AttrString-8 432B ± 0% 152B ± 0% ~ (p=1.000 n=1+1)
name old allocs/op new allocs/op delta
AttrString-8 30.0 ± 0% 16.0 ± 0% ~ (p=1.000 n=1+1)
Change-Id: I18ac91cbff1047d168b51a595601e36b5f676615
Reviewed-on: https://go-review.googlesource.com/c/go/+/573517
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Keep ReadTimeout, ReadHeaderTimeout, IdleTimeout and WriteTimeout in sync
Change-Id: I32b43884c0078eca86f20ec363f1d702ba298d1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/573315
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
Because issue #47631 has been fixed, remove TODO.
Change-Id: Ic476616729f47485a18a5145bd28c87dd18b4492
Reviewed-on: https://go-review.googlesource.com/c/go/+/573775
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This indirection appears to be unnecessary for linking or linker debugging, and therefore hinders readability.
Since all *oReaders are added to loader.objs *only* via the Preload -> addObj path, before any symbols are examined, there is no possible way the "i" member of this structure is still useful; and is likely a remnant of an earlier design.
Change-Id: Icd880f40bf3299bf1aa0a14cf217268e49ee90c5
GitHub-Last-Rev: dd2d512cbe
GitHub-Pull-Request: golang/go#57460
Reviewed-on: https://go-review.googlesource.com/c/go/+/459456
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
This CL is doing now is:
change maxbg to increase test parallelism.
adjust test sequence.
This CL speeds up the go tool dist test,
most of the speed up is due to the fact that the
three time-consuming tests
cmd/internal/testdir and API check and runtime/race
can be done in parallel with the GOMAXPROCS=2 runtime
on a machine with enough CPU cores.
In windows with an 8-core 16-thread CPU,
this CL can complete all other tests before
GOMAXPROCS=2 runtime -cpu=1,2,4 -quick completes.
Fixes#65164
Change-Id: I56ed7031d58be3bece9f975bfc73e5c834d0a4fa
GitHub-Last-Rev: 18cffb770f
GitHub-Pull-Request: golang/go#65703
Reviewed-on: https://go-review.googlesource.com/c/go/+/563916
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Surprisingly, newClientServerTest doesn't ensure that server handlers
are done in its t.Cleanup function. This test's handler can outlive
the test and attempt to log after the test has completed, causing
race detector failures.
Add an explicit call to Server.Shutdown to ensure the handler
has completed.
We should also probably add a Shutdown to clientServerTest.close,
but that's a larger change; this fixes the immediate problem.
Change-Id: Ibe81b4b382c9c8a920b0ff5f76dea6afe69b10f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/573895
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Change-Id: Ic1dd899fa52fdf9098955fc14a828d2f07da8037
GitHub-Last-Rev: 6e0438ec71
GitHub-Pull-Request: golang/go#66437
Reviewed-on: https://go-review.googlesource.com/c/go/+/573235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Change-Id: I020ca2ed8a6af60977f2c492cd742f824906d4ec
GitHub-Last-Rev: b27fda4630
GitHub-Pull-Request: golang/go#66462
Reviewed-on: https://go-review.googlesource.com/c/go/+/573715
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently ordering.Advance is one massive switch statement. This isn't
amazing for readability because it's hard to see at a glance what
happens before and after. Some of the state sharing is nice, but
otherwise, it can get confusing quickly (especially where break is used,
and where there are nested switches).
This CL breaks up the switch statement into individual methods on
ordering.Advance which are loaded and dispatched from a table. This CL
uses a table instead of a switch statement because the arguments passed
are all the same each time, and the table can provide a very precise
mapping for each event; with a switch, we'd be tempted to group cases
that call the same handler method together. It also prevents us from
using defer in many cases, which may help clean up the code. (Each case
in the switch is completely self-contained, yet we can't use a defer
because it's function-scoped.)
As an aside, this should also improve performance a bit. The Go compiler
doesn't handle massive irregular functions very well, especially one
with a lot of return points and (previously) a conditionally deferred
call.
Change-Id: I3ef2cf75301c795b6f23da1e058b0ac303fea8bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/566576
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
