cmd/compile: add all runtime package dependencies to NoInstrumentPkgs
Currently, this list includes *almost* all runtime packages, but not
quite all.
We leave out internal/bytealg for reasons explained in the code.
Compiling with or without race instrumentation has no effect on the
other packages added to the list here, so this is a no-op change
today, but makes this more robust.
This adds a test that all packages imported by runtime are marked as
runtime tests by LookupPkgSpecial. We add two packages that were
missing from the list.
Austin Clements [Fri, 30 Jun 2023 20:33:49 +0000 (16:33 -0400)]
cmd/compile,cmd/dist,cmd/go: compute -+ flag from package path
As we did for the asm -compiling-runtime flag, this CL modifies the
compiler to compute the -+ (compiling runtime) flag from the package
path. Unlike for asm, some tests use -+ explicitly to opt in to
runtime restrictions, so we leave the flag, but it's no longer passed
by any build tools.
This lets us eliminate cmd/go's list of "runtime packages" in favor of
the unified objabi.LookupPkgSpecial. It also fixes an inconsistency
with dist, which only passed -+ when compiling "runtime" itself.
One consequence of this is that the compiler now ignores the -N flag
when compiling runtime packages. Previously, cmd/go would strip -N
when passing -+ and the compiler would fatal if it got both -N and -+,
so the overall effect was that the compiler never saw -N when
compiling a runtime package. Now we simply move that logic to disable
-N down into the compiler.
There are several implementations of "is this package path a runtime
package". They all have slightly different lists because they all care
about slightly different properties of building the runtime.
To start converging these, we replace objabi.IsRuntimePackagePath with
objabi.LookupPkgSpecial, which returns a struct we can extend with
various special build properties. We'll extend this with several other
flags in the following CLs.
Austin Clements [Fri, 30 Jun 2023 20:33:49 +0000 (16:33 -0400)]
cmd/asm,cmd/dist,cmd/go: remove asm -compiling-runtime flag
Currently, dist and go pass a -compiling-runtime flag to asm if
they're compiling a runtime package. However, now that we always pass
the package path to asm, it can make that determination just as well
as its callers can. This CL moves that check into asm and drops the
flag.
This in turn makes dist's copy of IsRuntimePackagePath unnecessary, so
we delete it.
Currently, the types package has IsRuntimePkg and IsReflectPkg
predicates for testing if a Pkg is the runtime or reflect packages.
IsRuntimePkg returns "true" for any "CompilingRuntime" package, which
includes all of the packages imported by the runtime. This isn't
inherently wrong, except that all but one use of it is of the form "is
this Sym a specific runtime.X symbol?" for which we clearly only want
the package "runtime" itself. IsRuntimePkg was introduced (as
isRuntime) in CL 37538 as part of separating the real runtime package
from the compiler built-in fake runtime package. As of that CL, the
"runtime" package couldn't import any other packages, so this was
adequate at the time.
We could fix this by just changing the implementation of IsRuntimePkg,
but the meaning of this API is clearly somewhat ambiguous. Instead, we
replace it with a new RuntimeSymName function that returns the name of
a symbol if it's in package "runtime", or "" if not. This is what
every call site (except one) actually wants, which lets us simplify
the callers, and also more clearly addresses the ambiguity between
package "runtime" and the general concept of a runtime package.
IsReflectPkg doesn't have the same issue of ambiguity, but it
parallels IsRuntimePkg and is used in the same way, so we replace it
with a new ReflectSymName for consistency.
Michael Anthony Knyszek [Mon, 7 Aug 2023 19:09:59 +0000 (19:09 +0000)]
runtime: avoid MADV_HUGEPAGE for heap memory
Currently the runtime marks all new memory as MADV_HUGEPAGE on Linux and
manages its hugepage eligibility status. Unfortunately, the default
THP behavior on most Linux distros is that MADV_HUGEPAGE blocks while
the kernel eagerly reclaims and compacts memory to allocate a hugepage.
This direct reclaim and compaction is unbounded, and may result in
significant application thread stalls. In really bad cases, this can
exceed 100s of ms or even seconds.
Really all we want is to undo MADV_NOHUGEPAGE marks and let the default
Linux paging behavior take over, but the only way to unmark a region as
MADV_NOHUGEPAGE is to also mark it MADV_HUGEPAGE.
The overall strategy of trying to keep hugepages for the heap unbroken
however is sound. So instead let's use the new shiny MADV_COLLAPSE if it
exists.
MADV_COLLAPSE makes a best-effort synchronous attempt at collapsing the
physical memory backing a memory region into a hugepage. We'll use
MADV_COLLAPSE where we would've used MADV_HUGEPAGE, and stop using
MADV_NOHUGEPAGE altogether.
Because MADV_COLLAPSE is synchronous, it's also important to not
re-collapse huge pages if the huge pages are likely part of some large
allocation. Although in many cases it's advantageous to back these
allocations with hugepages because they're contiguous, eagerly
collapsing every hugepage means having to page in at least part of the
large allocation.
However, because we won't use MADV_NOHUGEPAGE anymore, we'll no longer
handle the fact that khugepaged might come in and back some memory we
returned to the OS with a hugepage. I've come to the conclusion that
this is basically unavoidable without a new madvise flag and that it's
just not a good default. If this change lands, advice about Linux huge
page settings will be added to the GC guide.
Verified that this change doesn't regress Sweet, at least not on my
machine with:
/sys/kernel/mm/transparent_hugepage/enabled [always or madvise]
/sys/kernel/mm/transparent_hugepage/defrag [madvise]
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none [0 or 511]
Unfortunately, this workaround means that we only get forced hugepages
on Linux 6.1+.
Fixes #61718.
Change-Id: I7f4a7ba397847de29f800a99f9cb66cb2720a533
Reviewed-on: https://go-review.googlesource.com/c/go/+/516795 Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Bryan C. Mills [Tue, 22 Aug 2023 15:01:29 +0000 (11:01 -0400)]
net/http: use testenv.Command instead of exec.Command in tests
On Unix platforms, testenv.Command sends SIGQUIT to stuck commands
before the test times out. For subprocesses that are written in Go,
that causes the runtime to dump running goroutines, and in other
languages it triggers similar behavior (such as a core dump).
If the subprocess is stuck due to a bug (such as #57999), that may
help to diagnose it.
Keith Randall [Mon, 21 Aug 2023 21:10:24 +0000 (14:10 -0700)]
cmd/compile: use better line numbers for write barriers
When the write barrier does several pointer writes under one
write barrier flag check, the line numbers aren't really correct.
The writes inside the write barrier have a confusing set of positions.
The loads of the old values are given the line number of the
corresponding store instruction, but the stores into the write buffer
are given the line number of the first store. Instead, give them all
line numbers corresponding to the store instruction.
The writes at the merge point, which are the original writes and the
only ones that happen when the barrier is off, are currently all given
the line number of the first write. Instead give them their original
line number.
Change-Id: Id64820b707f45f07b0978f8d03c97900fdc4bc0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/521499 Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Meng Zhuo [Wed, 28 Jun 2023 08:45:07 +0000 (16:45 +0800)]
cmd/compile: add single-precision FMA code generation for riscv64
This CL adds FMADDS,FMSUBS,FNMADDS,FNMSUBS SSA support for riscv
Change-Id: I1e7dd322b46b9e0f4923dbba256303d69ed12066
Reviewed-on: https://go-review.googlesource.com/c/go/+/506616 Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: M Zhuo <mzh@golangcn.org>
Ref: The RISC-V Instruction Set Manual Volume I: Unprivileged ISA
11.6 Single-Precision Floating-Point Computational Instructions
Change-Id: I89aa3a4df7576fdd47f4a6ee608ac16feafd093c
Reviewed-on: https://go-review.googlesource.com/c/go/+/506036 Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: M Zhuo <mzh@golangcn.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Joel Sing [Sat, 11 Mar 2023 15:15:43 +0000 (02:15 +1100)]
syscall: add support for openbsd/ppc64
Add syscall support for the openbsd/ppc64 port.
Updates #56001
Change-Id: I695c5c296e90645515de0c8f89f1bc57e976679d
Reviewed-on: https://go-review.googlesource.com/c/go/+/475636 Reviewed-by: Eric Grosse <grosse@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Joel Sing [Sat, 18 Mar 2023 08:51:52 +0000 (19:51 +1100)]
runtime: rework asmcgocall on ppc64x
On some platforms asmcgocall can be called with a nil g. Additionally, it
can be called when already on a the system (g0) stack or on a signal stack.
In these cases we do not need to switch (and/or cannot switch) to the
system stack and as a result, do not need to save the g.
Rework asmcgocall on ppc64x to follow the pattern used on other architectures,
such as amd64 and arm64, where a separate nosave path is called in the above
cases. The nil g case will be needed to support openbsd/ppc64.
Updates #56001
Change-Id: I431d4200bcbc4aaddeb617aefe18590165ff2927
Reviewed-on: https://go-review.googlesource.com/c/go/+/478775 Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Paul Murphy <murp@ibm.com>
Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Matthew Dempsky [Sun, 20 Aug 2023 17:05:29 +0000 (10:05 -0700)]
cmd/compile/internal/types: overhaul and simplify API
This CL removes a lot of the redundant methods for accessing struct
fields and signature parameters. In particular, users never have to
write ".Slice()" or ".FieldSlice()" anymore; the exported APIs just do
what you want.
Further internal refactorings to follow.
Change-Id: I45212f6772fe16aad39d0e68b82d71b0796e5639
Reviewed-on: https://go-review.googlesource.com/c/go/+/521295
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Rather than constructing a new runtime._defer struct type at each
defer statement, we can use a single shared one. Also, by naming it
runtime._defer, we avoid emitting new runtime and DWARF type
descriptors in every package that contains a "defer" statement.
Shaves ~1kB off cmd/go.
Change-Id: I0bd819aec9f856546e684abf620e339a7555e73f
Reviewed-on: https://go-review.googlesource.com/c/go/+/521676 Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Matthew Dempsky [Fri, 18 Aug 2023 22:52:34 +0000 (15:52 -0700)]
spec: clarify that []byte("") must be non-nil
The example text below suggests that []byte("") always evaluates to
the non-nil value []byte{}, but the text proper doesn't explicitly
require that. This CL makes it clear that it must not evaluate to
[]byte(nil), which otherwise was allowed by the wording.
Change-Id: I6564bfd5e2fd0c820d9b55d17406221ff93ce80c
Reviewed-on: https://go-review.googlesource.com/c/go/+/521035 Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Jes Cok [Sat, 19 Aug 2023 00:21:00 +0000 (00:21 +0000)]
os/exec: don't convert byte slice to string when using verb %s
Change-Id: I4d755e401acf670fb5a154ff59e4e4335ed2138e
GitHub-Last-Rev: a91d74ae55f84a0e572d2ace335ec42038d7a76f
GitHub-Pull-Request: golang/go#62150
Reviewed-on: https://go-review.googlesource.com/c/go/+/520918
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The go resolver shouldn't attempt to query .onion domains, but
the restriction was not restricted for search domains.
Also before this change query for "sth.onion" would
not be suffixed with any search domain (for "go.dev" search
domain, it should query fine the "std.onion.go.dev" domain).
Change-Id: I0f3e1387e0d59721381695f94586e3743603c30e
GitHub-Last-Rev: 7e8ec44078529353c18c8fe34e5207014ce1e685
GitHub-Pull-Request: golang/go#60678
Reviewed-on: https://go-review.googlesource.com/c/go/+/501701
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Matthew Dempsky [Sun, 20 Aug 2023 17:23:03 +0000 (10:23 -0700)]
cmd/compile/internal/compare: simplify unit test framework
This CL refactors the compare unit tests to be simpler and to stop
using the types API in non-idiomatic ways, to facilitate further
refactoring of the API.
Change-Id: I864a66b2842a0d8dd45f4e3d773144d71666caf2
Reviewed-on: https://go-review.googlesource.com/c/go/+/521275
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Matthew Dempsky [Sun, 20 Aug 2023 06:04:46 +0000 (23:04 -0700)]
cmd/compile/internal/abi: stop using types.Func
This is supposed to be an internal type within package types. At least
for now, users of the types package should stick to the types.Type
APIs as much as possible.
This CL also unexports FuncType and a few others to prevent
backsliding.
Change-Id: I053fc115a5e6a57c148c8149851a45114756072f
Reviewed-on: https://go-review.googlesource.com/c/go/+/521255
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Austin Clements [Tue, 1 Aug 2023 18:41:42 +0000 (14:41 -0400)]
runtime: drop stack-allocated pcvalueCaches
Now that pcvalue keeps its cache on the M, we can drop all of the
stack-allocated pcvalueCaches and stop carefully passing them around
between lots of operations. This significantly simplifies a fair
amount of code and makes several structures smaller.
This series of changes has no statistically significant effect on any
runtime Stack benchmarks.
I also experimented with making the cache larger, now that the impact
is limited to the M struct, but wasn't able to measure any
improvements.
Austin Clements [Tue, 1 Aug 2023 17:54:32 +0000 (13:54 -0400)]
runtime: move pcvalue cache to M
Currently, the pcvalue cache is stack allocated for each operation
that needs to look up a lot of pcvalues. It's not always clear where
to put it, a lot of the time we just pass a nil cache, it doesn't get
reused across operations, and we put a surprising amount of effort
into threading these caches around.
This CL moves it to the M, where it can be long-lived and used by all
pcvalue lookups, and we don't have to carefully thread it across
operations.
This is a re-roll of CL 515276 with a fix for reentrant use of the
pcvalue cache from the signal handler.
Keith Randall [Fri, 18 Aug 2023 19:38:32 +0000 (12:38 -0700)]
cmd/compile: ensure we keep top 32 bits zeroed for 32-bit arm64 ops
When rewriting, for example, MSUBW, we need to ensure that the result
has its 32 top bits zeroed. That's what the instruction is spec'd to do.
Normally, we'd only use MSUBW for computations on 32-bit values, and
as such the top 32 bits aren't normally used. But some situations, like
if we cast the result to a uint64, the top 32 bits do matter.
This comes up in 62131 because we have a rule saying, MOVWUreg applied
to a MSUBW is unnecessary, as the arg to MOVWUreg already has zeroed
top 32 bits. But if MSUBW is later rewritten to another op that doesn't
zero the top 32 bits (SUB, probably), getting rid of the MOVWUreg earlier
causes a problem.
So change rewrite rules to always maintain the top 32 bits as zero if the
instruction is spec'd to provide that. We need to introduce a few *W operations
to make that happen.
Fixes #62131
Change-Id: If3d160821e285fd7454746b735a243671bff8894
Reviewed-on: https://go-review.googlesource.com/c/go/+/520916
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
Bryan C. Mills [Mon, 21 Aug 2023 16:55:43 +0000 (12:55 -0400)]
context: fix synchronization in ExampleAfterFunc_cond
Condition variables are subtle and error-prone, and this example
demonstrates exactly the sorts of problems that they introduce.
Unfortunately, we're stuck with them for the foreseeable future.
As previously implemented, this example was racy: since the callback
passed to context.AfterFunc did not lock the mutex before calling
Broadcast, it was possible for the Broadcast to occur before the
goroutine was parked in the call to Wait, causing in a missed wakeup
resulting in deadlock.
The example also had a more insidious problem: it was not safe for
multiple goroutines to call waitOnCond concurrently, but the whole
point of using a sync.Cond is generally to synchronize concurrent
goroutines. waitOnCond must use Broadcast to ensure that it wakes up
the target goroutine, but the use of Broadcast in this way would
produce spurious wakeups for all of the other goroutines waiting on
the same condition variable. Since waitOnCond did not recheck the
condition in a loop, those spurious wakeups would cause waitOnCond
to spuriously return even if its own ctx was not yet done.
Fixing the aforementioned bugs exposes a final problem, inherent to
the use of condition variables in this way. This one is a performance
problem: for N concurrent calls to waitOnCond, the resulting CPU cost
is at least O(N²). This problem cannot be addressed without either
reintroducing one of the above bugs or abandoning sync.Cond in the
example entirely. Given that this example was already published in Go
1.21, I worry that Go users may think that it is appropriate to use a
sync.Cond in conjunction with context.AfterFunc, so I have chosen to
retain the Cond-based example and document its pitfalls instead of
removing or replacing it entirely.
I described this class of bugs and performance issues — and suggested
some channel-based alternatives — in my GopherCon 2018 talk,
“Rethinking Classical Concurrency Patterns”. The section on condition
variables starts on slide 37. (https://youtu.be/5zXAHh5tJqQ?t=679)
Bryan C. Mills [Fri, 18 Aug 2023 19:38:44 +0000 (15:38 -0400)]
cmd/go: find GOROOT using os.Executable when installed to GOROOT/bin/GOOS_GOARCH
When running make.bash in a cross-compiled configuration
(for example, GOARCH different from GOHOSTARCH), cmd/go
is installed to GOROOT/bin/GOOS_GOARCH instead of GOROOT/bin.
That means that we need to look for GOROOT in both ../.. and ../../..,
not just the former.
cmd/compile: move racewalk comment to walk/race.go
This comment got left behind in some refactoring and now refers to
code "below" that is no longer below. Move it to be with the code it's
referring to.
Andy Pan [Thu, 10 Aug 2023 06:02:03 +0000 (14:02 +0800)]
runtime: document maxStack and m.createstack in more details
Change-Id: If93b6cfa5a598a5f4101c879a0cd88a194e4a6aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/518116 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
This CL refactors common patterns for constructing field and method
selector expressions. Notably, XDotField and XDotMethod are now the
only two functions where a SelecterExpr with OXDOT is constructed.
Change-Id: I4c087225d8b295c4a6a92281ffcbcabafe2dc94d
Reviewed-on: https://go-review.googlesource.com/c/go/+/520979
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Matthew Dempsky [Sat, 19 Aug 2023 00:43:15 +0000 (17:43 -0700)]
cmd/compile/internal/typecheck: refactor and simplify DeclFunc
This CL refactors typecheck.DeclFunc to require the caller to have
already constructed the ir.Func and signature type using ir.NewFunc
and types.NewSignature, and simplifies typecheck.DeclFunc to simply
return the slices of param and results ONAMEs.
typecheck.DeclFunc was the last reason that ir.Field still exists, so
this CL also gets rid of that.
Change-Id: Ib398420bac2fd135a235810b8af1635fa754965c
Reviewed-on: https://go-review.googlesource.com/c/go/+/520977
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Mateusz Poliwczak [Sat, 19 Aug 2023 07:52:34 +0000 (07:52 +0000)]
net: return "cannot unmarshal" error while parsing DNS messages
Change-Id: I407f5d3d3a3e8b3d43ff154f731d885e831971e9
GitHub-Last-Rev: d6a400d1ba6a09e726c9b4e4774a7e8a611611e8
GitHub-Pull-Request: golang/go#62155
Reviewed-on: https://go-review.googlesource.com/c/go/+/520980
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com>
CL 521036 was prepared and tested before the revert CL 521155,
and it so happens that the reflectdata import ended up unused.
Drop it to fix the build.
Change-Id: I230c8fee616fc58cc82f3e5da886bcee2e02a3d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/521175
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@google.com>
Joe Tsai [Tue, 14 Mar 2023 22:35:36 +0000 (15:35 -0700)]
expvar: emit valid JSON strings
Map.String and expvarHandler used the %q flag with fmt.Fprintf
to escape Go strings, which does so according to the Go grammar,
which is not always compatible with JSON strings.
Rather than calling json.Marshal for every string,
which will always allocate, declare a local appendJSONQuote
function that does basic string escaping.
Also, we declare an unexported appendJSON method on every
concrete Var type so that the final JSON output can be
constructed with far fewer allocations.
The resulting logic is both more correct and also much faster.
This does not alter the whitespace style of Map.String or expvarHandler,
but may alter the representation of JSON strings.
Performance:
name old time/op new time/op delta
MapString 5.10µs ± 1% 1.56µs ± 1% -69.33% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
MapString 1.21kB ± 0% 0.66kB ± 0% -45.12% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
MapString 37.0 ± 0% 7.0 ± 0% -81.08% (p=0.000 n=10+10)
Fixes #59040
Change-Id: I46a2125f43550b91d52019e5edc003d9dd19590f
Reviewed-on: https://go-review.googlesource.com/c/go/+/476336 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Ian Lance Taylor [Fri, 18 Aug 2023 23:34:29 +0000 (16:34 -0700)]
encoding/csv: correct Column docs
For #44221
Fixes #62147
Change-Id: Ibcc0d11c8253f51a8f5771791ea4173a38a61950
Reviewed-on: https://go-review.googlesource.com/c/go/+/520917
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Andy Pan [Fri, 18 Aug 2023 05:39:57 +0000 (13:39 +0800)]
encoding/gob: prevent panic from index out of range in Decoder.typeString
I believe this bug is introduced by CL 460543 which optimizes the allocations
by changing the type of `idToType` from map to slice, but didn't update the
access code in `Decoder.typeString` that is safe for map but not for slice.
Fixes #62117
Change-Id: I0f2e4cc2f34c54dada1f83458ba512a6fde6dcbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/520757
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The only remaining use for typecheck.NeedRuntimeType is to make sure
that method expressions with anonymous receiver types (e.g.,
"struct{T}.M") have the promoted-method wrapper generated. But the
unified frontend takes care of arranging for this now.
Change-Id: I89340cb6a81343f35e0de1062610cbb993d3b6bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/521036
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Joe Tsai [Thu, 17 Aug 2023 04:27:15 +0000 (21:27 -0700)]
encoding: optimize growth behavior in Encoding.AppendDecode
The Encoding.DecodedLen API only returns the maximum length of the
expected decoded output, since it does not know about padding.
Since we have the input, we can do better by computing the
input length without padding, and then perform the DecodedLen
calculation as if there were no padding.
This avoids over-growing the destination slice if possible.
Over-growth is still possible since the input may contain
ignore characters like newlines and carriage returns,
but those a rarely encountered in practice.
Change-Id: I38b8f91de1f4fbd3a7128c491a25098bd385cf74
Reviewed-on: https://go-review.googlesource.com/c/go/+/520267
Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Joe Tsai [Fri, 18 Aug 2023 01:13:01 +0000 (18:13 -0700)]
time: make Duration.String inlineable
Perform the [32]byte to string conversion in an inlinable method.
Thus, if the result does not escape in the context of the caller,
we can entirely avoid a call to runtime.slicebytetostring.
Change-Id: Iae8ec2a532776ed6cf99597f19e3f7f21c694c3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/520602
Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Ian Lance Taylor <iant@google.com>
j178 [Fri, 18 Aug 2023 04:04:35 +0000 (12:04 +0800)]
errors: optimize Is and As by reusing reflection of target
goos: darwin
goarch: amd64
pkg: errors
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
│ old │ new │
│ sec/op │ sec/op vs base │
Is-12 133.4n ± 0% 126.8n ± 3% -4.91% (p=0.001 n=10)
As-12 464.1n ± 1% 307.2n ± 0% -33.80% (p=0.000 n=10)
geomean 248.8n 197.4n -20.66%
│ old │ new │
│ B/op │ B/op vs base │
Is-12 24.00 ± 0% 24.00 ± 0% ~ (p=1.000 n=10) ¹
As-12 40.00 ± 0% 40.00 ± 0% ~ (p=1.000 n=10) ¹
geomean 30.98 30.98 +0.00%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
Is-12 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹
As-12 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
geomean 1.414 1.414 +0.00%
¹ all samples are equal
Change-Id: I0844f3ab77e63b5f773594157dcffaffffd5e70d
Reviewed-on: https://go-review.googlesource.com/c/go/+/520756
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Matthew Dempsky [Fri, 18 Aug 2023 07:32:11 +0000 (00:32 -0700)]
cmd/compile/internal/gc: steps towards work-queue
This CL reorganizes the top-level functions for handling package-level
declarations, runtime type descriptors, and SSA compilation to work in
a loop. This generalizes the loop that previously existed in dumpdata.
Change-Id: I0e51e60f6ef9e7f96a4a3ccd5801f7baf83eba9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/520611
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Matthew Dempsky [Fri, 18 Aug 2023 07:09:06 +0000 (00:09 -0700)]
cmd/compile/internal/ir: remove AsNode
Except for a single call site in escape analysis, every use of
ir.AsNode involves a types.Object that's known to contain
an *ir.Name. Asserting directly to that type makes the code simpler
and more efficient.
The one use in escape analysis is extended to handle nil correctly
without it.
Change-Id: I694ae516903e541341d82c2f65a9155e4b0a9809
Reviewed-on: https://go-review.googlesource.com/c/go/+/520775
TryBot-Bypass: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Matthew Dempsky [Fri, 18 Aug 2023 06:23:40 +0000 (23:23 -0700)]
cmd/compile/internal/ir: remove Ntype
This type used to provide extra type safety around which syntactic
nodes could also represent types, but now the only remaining use is
ir.TypeNode, and it always ends up as an ir.Node anyway. So we might
as well use Node instead.
Change-Id: Ia0842864794365b0e155dc5af154c673ffa2967b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520609
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Matthew Dempsky [Fri, 18 Aug 2023 06:04:08 +0000 (23:04 -0700)]
cmd/compile/internal/ir: remove OFUNCINST and InstExpr
These were only ever used by the pre-unified generics frontend. I
initially kept them because I thought they'd be useful for the unified
frontend eventually too, but that hasn't manifested.
Change-Id: Iaa31a76ac4d62533ec269d2a7141442b8e344180
Reviewed-on: https://go-review.googlesource.com/c/go/+/520608
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Andy Pan [Fri, 18 Aug 2023 03:54:48 +0000 (11:54 +0800)]
encoding/json: use base64.Encoding.AppendEncode
For #53693
Change-Id: I6a428a4a10a2e2efa03296f539e190f0743c1f46
Reviewed-on: https://go-review.googlesource.com/c/go/+/520755 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Ian Lance Taylor [Fri, 18 Aug 2023 16:44:16 +0000 (09:44 -0700)]
spec: correct type parameter name used in example
Change-Id: I40595a3f598483d029473af465c756f8777ecc91
Reviewed-on: https://go-review.googlesource.com/c/go/+/520915 Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Chris O'Hara [Wed, 16 Aug 2023 01:14:53 +0000 (11:14 +1000)]
runtime/internal/wasitest: skip racy TCP echo test
The wasip1 TCP echo test introduced in CL 493358 has a race
condition with port selection. The test runner probes for a free
port and then asks the WASM runtime to listen on the port, which
may be taken by another process in the interim.
Due to limitations with WASI preview 1, the guest is unable to
query the port it's listening on. The test cannot ask the WASM
runtime to listen on port 0 (choose a free port) since there's
currently no way for the test to query the selected port and
connect to it.
Given the race condition is unavoidable, this test is now disabled
by default and requires opt-in via an environment variable.
This commit also eliminates the hard-coded connection timeout.
Fixes #61820.
Change-Id: I375145c1a1d03ad45c44f528da3347397e6dcb01
Reviewed-on: https://go-review.googlesource.com/c/go/+/519895
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
Michael Anthony Knyszek [Thu, 17 Aug 2023 18:36:00 +0000 (18:36 +0000)]
runtime/pprof: increase contention upper bound in TestMutexProfile
Currently TestMutexProfile expects contention to reported as somewhere
between 0.9x and 2.0x the expected amount introduced. While bounding
from below is fine (especially since the goroutine holding the mutex
doesn't even start to sleep until the required number of goroutines are
blocked on a mutex), bounding from above can easily lead to flakiness.
Delays and non-determinism can come from anywhere in the system,
and nevertheless clocks keep ticking. The result is that goroutines
could easily appear to be blocked on a mutex much longer than just the
sleep time.
However, the contention upper bound is still useful, especially for
identifying wildly incorrect values. Set the contention total to be
proportional to the total wall-time spent in the actual sampling mutex
block sampling portion of the code. This should be a generous
upper-bound on how much contention there could be, because it should in
theory capture any delays from the environment in it as well.
Still, rounding errors could be an issue, and on Windows the time
granularity is quite low (~15ms, or 15% of what each goroutine is
supposed to add to the mutex profile), so getting unlucky with where
time measurements fall within each tick could also be a problem. Add an
extra 10%, which seems to make it much less likely to fail in a Windows
gomote.
Fixes #62094.
Change-Id: I59a10a73affd077185dada8474b91d0bc43b4a43
Reviewed-on: https://go-review.googlesource.com/c/go/+/520635
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Cherry Mui [Fri, 18 Aug 2023 15:10:23 +0000 (11:10 -0400)]
cmd/link: don't mangle string symbol names
String symbol names could contain weird characters as we put the
string literal into the symbol name. So it may appear to need
mangling. However, as string symbols are grouped into a single
"go:string.*" symbol, the individual symbol names actually don't
matter. So don't mangle them.
Also make the mangling code more defensive in case of weird
symbol names.
Fixes #62098.
Change-Id: I533012567a9fffab69debda934f426421c7abb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/520856 Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL implements the remainder of the zero-copy string->[]byte
conversion optimization initially attempted in go.dev/cl/520395, but
fixes the tracking of mutations due to ODEREF/ODOTPTR assignments, and
adds more comprehensive tests that I should have included originally.
However, this CL also keeps it behind the -d=zerocopy flag. The next
CL will enable it by default (for easier rollback).
Updates #2205.
Change-Id: Ic330260099ead27fc00e2680a59c6ff23cb63c2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/520599
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Joe Tsai [Thu, 22 Jun 2023 18:44:55 +0000 (11:44 -0700)]
encoding: require unique alphabet for base32 and base64
In order for decoding to faithfully reproduce the encoded input,
the symbols must be unique (i.e., provide a bijective mapping).
Thus, reject duplicate symbols in NewEncoding.
As a minor optimization, modify WithPadding to use the decodeMap
to quickly check whether the padding character is used in O(1)
instead of O(32) or O(64).
Change-Id: I5631f6ff9335c35d59d020dc0e307e3520786fbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/520335 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Robert Griesemer [Mon, 14 Aug 2023 21:21:53 +0000 (14:21 -0700)]
spec: fix unification rule for inexact interface unification
Irrespective of whether unification is exact or inexact, method
signatures of interfaces must always match exactly: a type never
satisfies/implements an interface if relevant method signatures
are different (i.e., not identical, possibly after substitution).
This change matches the fix https://go.dev/cl/519435.
For #61879.
Change-Id: I28b0a32d32626d85afd32e107efce141235a923d
Reviewed-on: https://go-review.googlesource.com/c/go/+/519455
TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Ian Lance Taylor [Thu, 17 Aug 2023 20:03:21 +0000 (13:03 -0700)]
cmd/internal/buildid: don't crash on 0 phdr.p_align field
A 0 in phdr.p_align is the same as 1, meaning no alignment.
Fixes #62097
Change-Id: I931bab443fd6a89b5b45c8f99ead217f02e9b453
Reviewed-on: https://go-review.googlesource.com/c/go/+/520597
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
This CL enables the latent support for string->[]byte conversions
added go.dev/cl/520259.
One catch is that we need to make sure []byte("") evaluates to a
non-nil slice, even if "" is (nil, 0). This CL addresses that by
adding a "ptr != nil" check for OSTR2BYTESTMP, unless the NonNil flag
is set.
The existing uses of OSTR2BYTESTMP (which aren't concerned about
[]byte("") evaluating to nil) are updated to set this flag.
Fixes #2205.
Change-Id: I35a9cb16c164cd86156b7560915aba5108d8b523
Reviewed-on: https://go-review.googlesource.com/c/go/+/520395
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL removes the extra complexity from escape analysis that was
only needed to support go/defer normalization. It does not affect
analysis results at all.
Change-Id: I75785e0cb4c4ce19bea3b8df0bf95821bd885291
Reviewed-on: https://go-review.googlesource.com/c/go/+/520261
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Normalizing go/defer statements to always use functions with zero
parameters and zero results was added to escape analysis, because that
was the earliest point at which all three frontends converged. Now
that we only have the unified frontend, we can do it during typecheck,
which is where we perform all other desugaring and normalization
rewrites.
Change-Id: Iebf7679b117fd78b1dffee2974bbf85ebc923b23
Reviewed-on: https://go-review.googlesource.com/c/go/+/520260 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
I previously used a clumsy hack to copy Closgen back and forth while
inlining, to handle when an inlined function contains closures, which
need to each be uniquely numbered.
The real solution was to name the closures using r.inlCaller, rather
than r.curfn. This CL adds a helper method to do exactly this.
Change-Id: I510553b5d7a8f6581ea1d21604e834fd6338cb06
Reviewed-on: https://go-review.googlesource.com/c/go/+/520339
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Matthew Dempsky [Thu, 17 Aug 2023 02:45:12 +0000 (19:45 -0700)]
cmd/compile: cleanup Func construction
This CL moves more common Func-setup logic into ir.NewFunc. In
particular, it now handles constructing the Name and wiring them
together, setting the Typecheck bit, and setting Sym.Func.
Relatedly, this CL also extends typecheck.DeclFunc to append the
function to typecheck.Target.Funcs, so that callers no longer need to
do this.
Change-Id: Ifa0aded8df0517188eb295d0dccc107af85f1e8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/520338
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
This CL extends ir.NewClosureFunc to take the signature type argument,
and to handle naming the closure and adding it to typecheck.Target.
It also removes the code for typechecking OCLOSURE and ODCLFUNC nodes,
by having them always constructed as typechecked. ODCLFUNC node
construction will be further simplified in the followup CL.
Change-Id: Iabde4557d33051ee470a3bc4fd49599490024cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/520337
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Joe Tsai [Thu, 23 Mar 2023 08:01:46 +0000 (01:01 -0700)]
log/slog: simplify and optimize RFC3339 handling
In CL 421877 and CL 444278, time.Time.AppendFormat has been
specially optimized for the time.RFC3339Nano representation.
Relying on that optimization and modify the output to obtain the
fixed-width millisecond resolution that slog uses.
This both removes a lot of code and also improves performance:
name old time/op new time/op delta
WriteTime 93.0ns ± 1% 80.8ns ± 0% -13.17% (p=0.000 n=8+9)
Change-Id: I61e8f4476c111443e3e2098a45b2c21a76137345
Reviewed-on: https://go-review.googlesource.com/c/go/+/478757 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
chanxuehong [Thu, 17 Aug 2023 01:58:22 +0000 (01:58 +0000)]
math/big, math/rand: use the built-in max function
Change-Id: I71a38dd20bfaf2b1aed18892d54eeb017d3d7d66
GitHub-Last-Rev: 8da43b2cbd563ed123690709e519c9f84272b332
GitHub-Pull-Request: golang/go#61955
Reviewed-on: https://go-review.googlesource.com/c/go/+/518595
Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com>