]> Cypherpunks repositories - gostls13.git/log
gostls13.git
2 months agocmd/doc: add more convenient behavior for go doc -http with no args
Michael Matloob [Wed, 21 May 2025 19:19:16 +0000 (15:19 -0400)]
cmd/doc: add more convenient behavior for go doc -http with no args

If we're in a module, go to the module's page. Outside of a module, but
in a workspace go to the home page, and outside of a module or
workspace, show the stdlib docs.

For #68106

Change-Id: I911a90a0e2b0a2bbb622f56e32827d5bdfa7f2fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/675235
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
2 months agoruntime: use DontUpdate testprog for DontUpdate test
Michael Pratt [Wed, 21 May 2025 18:49:40 +0000 (14:49 -0400)]
runtime: use DontUpdate testprog for DontUpdate test

This is a typo in CL 670497. The test is using the wrong testprog
function.

The testprog also needs to assert that GOMAXPROCS doesn't change, not
that it is equal to NumCPU, for the GOMAXPROCS=4 case.

For #73193.

Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: I6a6a636cab6936aa8519e3553b70ab6641ca8010
Reviewed-on: https://go-review.googlesource.com/c/go/+/675097
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agocrypto/tls: update BoGo SessionID test skip reasons
Daniel McCarney [Fri, 16 May 2025 19:05:43 +0000 (15:05 -0400)]
crypto/tls: update BoGo SessionID test skip reasons

Updates the skip reason for the following BoGo tests:

  * TLS-ECH-Client-TLS12SessionID
  * SupportTicketsWithSessionID
  * ResumeTLS12SessionID-TLS13

The crypto/tls package does not support session ID based resumption at
this time, and so any tests that rely on this support need to be
skipped.

Updates #72006
Updates #25228

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/673737
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2 months agocrypto/tls: enable BoGo DisabledCurve-HelloRetryRequest-TLS13
Daniel McCarney [Fri, 16 May 2025 18:40:27 +0000 (14:40 -0400)]
crypto/tls: enable BoGo DisabledCurve-HelloRetryRequest-TLS13

The crypto/tls package produces the expected error for this test case,
and so it can be enabled.

Looking at the history of the relevant code it appears the TLS 1.3
implementation has always had the correct behaviour for HRR changing to
an unsupported group after the initial hello.

I think this test was skipped initially because at the time of
initial BoGo config commit we hadn't implemented the -curves argument
for the test shim yet, and this test relies on it. We later added
support for that flag alongside X25519Kyber768Draft00 KX and I think we
missed the chance to enable the test then.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/673756
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>

2 months agocrypto/tls: match compression method alert across versions
Daniel McCarney [Fri, 16 May 2025 17:44:53 +0000 (13:44 -0400)]
crypto/tls: match compression method alert across versions

When a pre-TLS 1.3 server processes a client hello message that
indicates compression methods that don't include the null compression
method, send an illegal parameter alert.

Previously we did this for TLS 1.3 server handshakes only, and the
legacy TLS versions used alertHandshakeFailure for this circumstance. By
switching this to alertIllegalParameter we use a consistent alert across
all TLS versions, and can also enable the NoNullCompression-TLS12 BoGo
test we were skipping.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/673736
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2 months agocrypto/tls: delete dead code curveIDForCurve
Daniel McCarney [Fri, 16 May 2025 17:34:14 +0000 (13:34 -0400)]
crypto/tls: delete dead code curveIDForCurve

This unexported function has no call-sites.

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/673755
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>

2 months agocrypto/tls: verify server chooses advertised curve
Daniel McCarney [Fri, 16 May 2025 17:08:16 +0000 (13:08 -0400)]
crypto/tls: verify server chooses advertised curve

When a crypto/tls client using TLS < 1.3 sends supported elliptic_curves
in a client hello message the server must limit itself to choosing one
of the supported options from our message. If we process a server key
exchange message that chooses an unadvertised curve, abort the
handshake w/ an error.

Previously we would not note that the server chose a curve we didn't
include in the client hello message, and would proceed with the
handshake as long as the chosen curve was one that we've implemented.
However, RFC 8422 5.1 makes it clear this is a server acting
out-of-spec, as it says:

  If a server does not understand the Supported Elliptic Curves
  Extension, does not understand the Supported Point Formats Extension,
  or is unable to complete the ECC handshake while restricting itself
  to the enumerated curves and point formats, it MUST NOT negotiate the
  use of an ECC cipher suite.

Changing our behaviour to enforce this also allows enabling the
UnsupportedCurve BoGo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673735
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2 months agoreflect: optimize IsZero with a pointer comparison to global zeroVal
thepudds [Sat, 1 Mar 2025 19:30:03 +0000 (14:30 -0500)]
reflect: optimize IsZero with a pointer comparison to global zeroVal

Our prior CL 649078 teaches the compiler to use a pointer to
runtime.zeroVal as the data pointer for an interface in cases it where
it can see that a zero value struct or array is being used in
an interface conversion.

This applies to some uses with reflect, such as:

  s := S{}
  v := reflect.ValueOf(s)

This CL builds on that to do a cheap pointer check in reflect.IsZero
to see if the Value points to runtime.zeroVal, which means it is a zero
value.

An alternative might be to do an initial pointer check in the typ.Equal
function for types where it makes sense to do but doesn't already.

This CL gives a performance boost of -51.71% geomean for
BenchmarkZero/IsZero, with most of the impact there on
arrays of structs. (The left column is CL 649078 and the right column
is this CL).

goos: linux
goarch: amd64
pkg: reflect
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
                                         │ find-zeroVal │          check-zeroVal              │
                                         │    sec/op    │   sec/op     vs base                │
Zero/IsZero/ByteArray/size=16-4             4.171n ± 0%   3.123n ± 0%  -25.13% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=64-4             3.864n ± 0%   3.129n ± 0%  -19.02% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=1024-4           3.878n ± 0%   3.126n ± 0%  -19.39% (p=0.000 n=20)
Zero/IsZero/BigStruct/size=1024-4           5.061n ± 0%   3.273n ± 0%  -35.34% (p=0.000 n=20)
Zero/IsZero/SmallStruct/size=16-4           4.191n ± 0%   3.275n ± 0%  -21.87% (p=0.000 n=20)
Zero/IsZero/SmallStructArray/size=64-4      8.636n ± 0%   3.127n ± 0%  -63.79% (p=0.000 n=20)
Zero/IsZero/SmallStructArray/size=1024-4   80.055n ± 0%   3.126n ± 0%  -96.10% (p=0.000 n=20)
Zero/IsZero/Time/size=24-4                  3.865n ± 0%   3.274n ± 0%  -15.29% (p=0.000 n=20)
geomean                                     6.587n        3.181n       -51.71%

Note these are of course micro benchmarks with easily predicted
branches. The extra branch we introduce in the CL might hurt if there
was for example a tight loop where 50% of the values used the
global zeroVal and 50% didn't in a way that is not well predicted,
although if the typ.Equal for many types already does an initial
pointer check, it might not matter much.

For the older BenchmarkIsZero in reflect, this change does not help.
(The compiler does not use the global zeroVal as the data word for the
interfaces in this benchmark because values are part of a larger value
that is too big to be used in the global zeroVal, and also a piece of
the larger value is mutated and is not zero).

                              │ find-zeroVal │           check-zeroVal            │
                              │   sec/op     │   sec/op     vs base               │
IsZero/ArrayComparable-4        14.58n ± 0%    14.59n ± 0%       ~ (p=0.177 n=20)
IsZero/ArrayIncomparable-4      163.8n ± 0%    167.5n ± 0%  +2.26% (p=0.000 n=20)
IsZero/StructComparable-4       6.847n ± 0%    6.847n ± 0%       ~ (p=0.703 n=20)
IsZero/StructIncomparable-4     35.41n ± 0%    35.10n ± 0%  -0.86% (p=0.000 n=20)
IsZero/ArrayInt_4-4             8.631n ± 0%    8.363n ± 0%  -3.10% (p=0.000 n=20)
IsZero/ArrayInt_1024-4          265.5n ± 0%    265.4n ± 0%       ~ (p=0.288 n=20)
IsZero/ArrayInt_1024_NoZero-4   135.8n ± 0%    136.2n ± 0%  +0.33% (p=0.000 n=20)
IsZero/Struct4Int-4             8.451n ± 0%    8.386n ± 0%  -0.77% (p=0.000 n=20)
IsZero/ArrayStruct4Int_1024-4   265.2n ± 0%    266.0n ± 0%  +0.30% (p=0.000 n=20)
IsZero/ArrayChanInt_1024-4      265.5n ± 0%    265.4n ± 0%       ~ (p=0.605 n=20)
IsZero/StructInt_512-4          135.8n ± 0%    135.8n ± 0%       ~ (p=0.396 n=20)
geomean                         55.22n         55.12n       -0.18%

Updates #71323

Change-Id: Ie083853a5bff03856277a293d94532a681f4a8d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/654135
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
2 months agocmd/compile/internal/walk: use global zeroVal in interface conversions for zero values
thepudds [Wed, 12 Feb 2025 23:45:42 +0000 (18:45 -0500)]
cmd/compile/internal/walk: use global zeroVal in interface conversions for zero values

This is a small-ish adjustment to the change earlier in our
stack in CL 649555, which started creating read-only global storage
for a composite literal used in an interface conversion and setting
the interface data pointer to point to that global storage.

In some cases, there are execution-time performance benefits to point
to runtime.zeroVal in particular. In reflect, pointer checks against
the runtime.zeroVal memory address are used to side-step some work,
such as in reflect.Value.Set and reflect.Value.IsZero.

In this CL, we therefore dig up the zeroVal symbol, and we use the
machinery from earlier in our stack to use a pointer to zeroVal for
the interface data pointer if we see examples like:

    sink = S{}
or:
    s := S{}
    sink = s

CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.

We add a benchmark in reflect to show examples of performance benefit.
The left column is our immediately prior CL 649555, and the right is
this CL. (The arrays of structs here do not seem to benefit, which
we attempt to address in our next CL).

goos: linux
goarch: amd64
pkg: reflect
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
                                          │  cl-649555   │           new                       │
                                          │    sec/op    │   sec/op     vs base                │
Zero/IsZero/ByteArray/size=16-4              4.176n ± 0%   4.171n ± 0%        ~ (p=0.151 n=20)
Zero/IsZero/ByteArray/size=64-4              6.921n ± 0%   3.864n ± 0%  -44.16% (p=0.000 n=20)
Zero/IsZero/ByteArray/size=1024-4           21.210n ± 0%   3.878n ± 0%  -81.72% (p=0.000 n=20)
Zero/IsZero/BigStruct/size=1024-4           25.505n ± 0%   5.061n ± 0%  -80.15% (p=0.000 n=20)
Zero/IsZero/SmallStruct/size=16-4            4.188n ± 0%   4.191n ± 0%        ~ (p=0.106 n=20)
Zero/IsZero/SmallStructArray/size=64-4       8.639n ± 0%   8.636n ± 0%        ~ (p=0.973 n=20)
Zero/IsZero/SmallStructArray/size=1024-4     79.99n ± 0%   80.06n ± 0%        ~ (p=0.213 n=20)
Zero/IsZero/Time/size=24-4                   7.232n ± 0%   3.865n ± 0%  -46.56% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=16-4             13.47n ± 0%   13.09n ± 0%   -2.78% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=64-4             14.14n ± 0%   13.70n ± 0%   -3.15% (p=0.000 n=20)
Zero/SetZero/ByteArray/size=1024-4           24.22n ± 0%   20.18n ± 0%  -16.68% (p=0.000 n=20)
Zero/SetZero/BigStruct/size=1024-4           24.24n ± 0%   20.18n ± 0%  -16.73% (p=0.000 n=20)
Zero/SetZero/SmallStruct/size=16-4           13.45n ± 0%   13.10n ± 0%   -2.60% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=64-4      14.12n ± 0%   13.69n ± 0%   -3.05% (p=0.000 n=20)
Zero/SetZero/SmallStructArray/size=1024-4    24.62n ± 0%   21.61n ± 0%  -12.26% (p=0.000 n=20)
Zero/SetZero/Time/size=24-4                  13.59n ± 0%   13.40n ± 0%   -1.40% (p=0.000 n=20)
geomean                                      14.06n        10.19n       -27.54%

Finally, here are results from the benchmark example from #71323.
Note however that almost all the benefit shown here is from our earlier
CL 649555, which is a more general purpose change and eliminates
the allocation using a different read-only global than this CL.

             │   go1.24       │               new                    │
             │     sec/op     │    sec/op     vs base                │
InterfaceAny   112.6000n ± 5%   0.8078n ± 3%  -99.28% (p=0.000 n=20)
ReflectValue      11.63n ± 2%    11.59n ± 0%        ~ (p=0.330 n=20)

             │  go1.24.out  │                 new.out                 │
             │     B/op     │    B/op     vs base                     │
InterfaceAny   224.0 ± 0%       0.0 ± 0%  -100.00% (p=0.000 n=20)
ReflectValue   0.000 ± 0%     0.000 ± 0%         ~ (p=1.000 n=20) ¹

             │  go1.24.out  │                 new.out                 │
             │  allocs/op   │ allocs/op   vs base                     │
InterfaceAny   1.000 ± 0%     0.000 ± 0%  -100.00% (p=0.000 n=20)
ReflectValue   0.000 ± 0%     0.000 ± 0%         ~ (p=1.000 n=20) ¹

Updates #71359
Updates #71323

Change-Id: I64d8cf1a7900f011d2ec59b948388aeda1150676
Reviewed-on: https://go-review.googlesource.com/c/go/+/649078
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
2 months agocmd/compile/internal/walk: convert composite literals to interfaces without allocating
thepudds [Fri, 14 Feb 2025 04:49:50 +0000 (23:49 -0500)]
cmd/compile/internal/walk: convert composite literals to interfaces without allocating

Today, this interface conversion causes the struct literal
to be heap allocated:

    var sink any

    func example1() {
        sink = S{1, 1}
    }

For basic literals like integers that are directly used in
an interface conversion that would otherwise allocate, the compiler
is able to use read-only global storage (see #18704).

This CL extends that to struct and array literals as well by creating
read-only global storage that is able to represent for example S{1, 1},
and then using a pointer to that storage in the interface
when the interface conversion happens.

A more challenging example is:

    func example2() {
        v := S{1, 1}
        sink = v
    }

In this case, the struct literal is not directly part of the
interface conversion, but is instead assigned to a local variable.

To still avoid heap allocation in cases like this, in walk we
construct a cache that maps from expressions used in interface
conversions to earlier expressions that can be used to represent the
same value (via ir.ReassignOracle.StaticValue). This is somewhat
analogous to how we avoided heap allocation for basic literals in
CL 649077 earlier in our stack, though here we also need to do a
little more work to create the read-only global.

CL 649076 (also earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.

See the writeup in #71359 for details.

Fixes #71359
Fixes #71323
Updates #62653
Updates #53465
Updates #8618

Change-Id: I8924f0c69ff738ea33439bd6af7b4066af493b90
Reviewed-on: https://go-review.googlesource.com/c/go/+/649555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
2 months agointernal/godebug,crypto/fips140: make fips140 setting immutable
Filippo Valsorda [Wed, 12 Mar 2025 17:02:39 +0000 (18:02 +0100)]
internal/godebug,crypto/fips140: make fips140 setting immutable

Updates #70123

Co-authored-by: qmuntal <quimmuntal@gmail.com>
Change-Id: I6a6a4656fd23ecd82428cccbd7c48692287fc75a
Reviewed-on: https://go-review.googlesource.com/c/go/+/657116
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
2 months agocrypto/internal/fips140: use hash.Hash
Filippo Valsorda [Wed, 21 May 2025 17:41:06 +0000 (19:41 +0200)]
crypto/internal/fips140: use hash.Hash

Since package hash is just the interface definition, not an
implementation, we can make a good argument that it doesn't impact the
security of the module and can be imported from outside.

For #69521

Change-Id: I6a6a4656b9c3cac8bb9ab8e8df11fa3238dc5d1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/674917
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

2 months agocmd/compile: fix offset calculation error in memcombine
Junyang Shao [Wed, 21 May 2025 18:50:39 +0000 (18:50 +0000)]
cmd/compile: fix offset calculation error in memcombine

Fixes #73812

Change-Id: If7a6e103ae9e1442a2cf4a3c6b1270b6a1887196
Reviewed-on: https://go-review.googlesource.com/c/go/+/675175
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocrypto/tls: have servers prefer TLS 1.3 when supported
Daniel McCarney [Thu, 15 May 2025 17:41:14 +0000 (13:41 -0400)]
crypto/tls: have servers prefer TLS 1.3 when supported

Previously the common Config.mutualVersion() code prioritized the
selected version based on the provided peerVersions being sent in peer
preference order.

Instead we would prefer to see TLS 1.3 used whenever it is
supported, even if the peer would prefer an older protocol version.
This commit updates mutualVersions() to implement this policy change.

Our new behaviour matches the behaviour of other TLS stacks, notably
BoringSSL, and so also allows enabling the IgnoreClientVersionOrder BoGo
test that we otherwise must skip.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/673236
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2 months agocrypto/tls: add GetEncryptedClientHelloKeys
Roland Shoemaker [Wed, 7 May 2025 18:37:52 +0000 (11:37 -0700)]
crypto/tls: add GetEncryptedClientHelloKeys

This allows servers to rotate their ECH keys without needing to restart
the server.

Fixes #71920

Change-Id: I55591ab3303d5fde639038541c50edcf1fafc9aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/670655
TryBot-Bypass: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2 months agocrypto/sha1: use cryptotest.TestAllImplementations and impl.Register
Filippo Valsorda [Wed, 21 May 2025 12:29:26 +0000 (14:29 +0200)]
crypto/sha1: use cryptotest.TestAllImplementations and impl.Register

Not running TryBots on s390x because the new LUCI builder is broken.

Change-Id: I6a6a4656a8d52fa5ace9effa67a88fbfd7d19b04
Reviewed-on: https://go-review.googlesource.com/c/go/+/674915
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>

2 months agocrypto: drop pre-AVX2 SHA assembly implementations
Roland Shoemaker [Fri, 14 Mar 2025 00:04:30 +0000 (17:04 -0700)]
crypto: drop pre-AVX2 SHA assembly implementations

Drop the entire pre-AVX2 assembly implementation of SHA-1, SHA-256, and
SHA-512. This also technically impacts the SHA-1 AVX2 implementation,
since it previously called the pre-AVX2 implementation for the last
block if the number of blocks wasn't a multiple of 2.

Instead of keeping the entire implementation just for that case, we
just call the generic implementation for the last block. This will be a
little slower, but still seems like a win.

Updates #69587

Change-Id: Id5234c42910d8c6ec6b8df700a721c0953dff02b
Reviewed-on: https://go-review.googlesource.com/c/go/+/657716
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
2 months agocrypto/internal/fips140/sha3: remove usages of WORD for s390x
Roland Shoemaker [Thu, 8 May 2025 17:27:34 +0000 (10:27 -0700)]
crypto/internal/fips140/sha3: remove usages of WORD for s390x

We support KIMD and KLMD now, paves the way for banning usage of BYTE
and WORD instructions in crypto assembly.

Change-Id: I0f93744663f23866b2269591db70389e0c77fa4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/671095
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2 months agocmd/compile/internal: intrinsify publicationBarrier on mipsx
Julian Zhu [Wed, 21 May 2025 08:36:53 +0000 (16:36 +0800)]
cmd/compile/internal: intrinsify publicationBarrier on mipsx

This enables publicationBarrier to be used as an intrinsic on mipsx.

Change-Id: Ic199f34b84b3058bcfab79aac8f2399ff21a97ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/674856
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
2 months agocrypto/x509: disallow negative path length
Mateusz Poliwczak [Tue, 20 May 2025 16:21:22 +0000 (16:21 +0000)]
crypto/x509: disallow negative path length

pathLenConstraint is restricted to unsigned integers.
Also the -1 value of cert.MaxPathLength has a special
meaning, so we shouldn't allow unmarshaling -1.

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

Change-Id: I485a6aa7223127becc86c423e1ef9ed2fbd48209
GitHub-Last-Rev: 75a11b47b963ac383d1ad67dfc001648632a05f0
GitHub-Pull-Request: golang/go#60706
Reviewed-on: https://go-review.googlesource.com/c/go/+/502076
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2 months agocmd/compile/internal: intrinsify publicationBarrier on mips64x
Julian Zhu [Tue, 20 May 2025 02:55:33 +0000 (10:55 +0800)]
cmd/compile/internal: intrinsify publicationBarrier on mips64x

This enables publicationBarrier to be used as an intrinsic on mips64x.

Change-Id: I4030ea65086c37ee1dcc1675d0d5d40ef8683851
Reviewed-on: https://go-review.googlesource.com/c/go/+/674855
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2 months agointernal/trace: skip clock snapshot checks on Windows in stress mode
Michael Anthony Knyszek [Wed, 21 May 2025 17:50:15 +0000 (17:50 +0000)]
internal/trace: skip clock snapshot checks on Windows in stress mode

Windows' monotonic and wall clock granularity is just too coarse to get
reasonable values out of stress mode, which is creating new trace
generations constantly.

Fixes #73813.

Change-Id: Id9cb2fed9775ce8d78a736d0164daa7bf45075e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/675096
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile/internal/escape: propagate constants to interface conversions to avoid...
thepudds [Wed, 12 Feb 2025 23:55:04 +0000 (18:55 -0500)]
cmd/compile/internal/escape: propagate constants to interface conversions to avoid allocs

Currently, the integer value in the following interface conversion gets
heap allocated:

   v := 1000
   fmt.Println(v)

In contrast, this conversion does not currently cause the integer value
to be heap allocated:

   fmt.Println(1000)

The second example is able to avoid heap allocation because of an
optimization in walk (by Josh in #18704 and related issues) that
recognizes a literal is being used. In the first example, that
optimization is currently thwarted by the literal getting assigned
to a local variable prior to use in the interface conversion.

This CL propagates constants to interface conversions like
in the first example to avoid heap allocations, instead using
a read-only global. The net effect is roughly turning the first example
into the second.

One place this comes up in practice currently is with logging or
debug prints. For example, if we have something like:

   func conditionalDebugf(format string, args ...interface{}) {
    if debugEnabled {
    fmt.Fprintf(io.Discard, format, args...)
    }
   }

Prior to this CL, this integer is heap allocated, even when the
debugEnabled flag is false, and even when the compiler
inlines conditionalDebugf:

   v := 1000
   conditionalDebugf("hello %d", v)

With this CL, the integer here is no longer heap allocated, even when
the debugEnabled flag is enabled, because the compiler can now see that
it can use a read-only global.

See the writeup in #71359 for more details.

CL 649076 (earlier in our stack) added most of the tests
along with debug diagnostics in convert.go to make it easier
to test this change.

Updates #71359
Updates #62653
Updates #53465
Updates #8618

Change-Id: I19a51e74b36576ebb0b9cf599267cbd2bd847ce4
Reviewed-on: https://go-review.googlesource.com/c/go/+/649079
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: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
2 months agocmd/compile/internal/escape: use an ir.ReassignOracle
thepudds [Fri, 4 Apr 2025 19:51:16 +0000 (15:51 -0400)]
cmd/compile/internal/escape: use an ir.ReassignOracle

Using the new-ish ir.ReassignOracle is more efficient than calling
ir.StaticValue repeatedly.

This CL now uses an ir.ReassignOracle for the recent
make constant propagation introduced in CL 649035.

We also pull the main change from CL 649035 into a new function,
which we will update later in our stack. We will also use the
ReassignOracles introduced here later in our stack.

(We originally did most of this work in CL 649077, but we abandoned
that in favor of CL 649035).

We could also use an ir.ReassignOracle in the older processing of
ir.OCALLFUNC in (*escape).call, but for now, we just leave that
as a TODO.

Updates #71359

Change-Id: I6e02eeac269bde3a302622b4dfe0c8dc63ec9ffc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673795
Reviewed-by: Keith Randall <khr@google.com>
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: David Chase <drchase@google.com>
2 months agoos: add Root.ReadFile and Root.WriteFile
Damien Neil [Mon, 19 May 2025 22:51:14 +0000 (15:51 -0700)]
os: add Root.ReadFile and Root.WriteFile

For #73126

Change-Id: Ie69cc274e7b59f958c239520318b89ff0141e26b
Reviewed-on: https://go-review.googlesource.com/c/go/+/674315
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>

2 months agolog/slog: add GroupAttrs
Sean Liao [Wed, 14 May 2025 20:26:57 +0000 (21:26 +0100)]
log/slog: add GroupAttrs

GroupAttrs is a more efficient version of Group
that takes a slice of Attr values.

Fixes #66365

Change-Id: Ic3046704825e17098f2fea5751f2959dce1073e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/672915
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agoruntime: skip windows stack tests in race mode
Michael Pratt [Wed, 21 May 2025 17:36:42 +0000 (13:36 -0400)]
runtime: skip windows stack tests in race mode

These became race instrumented in CL 643897, but race mode uses more
memory, so the test doesn't make much sense.

For #71395.

Change-Id: I6a6a636cf09ba29625aa9a22550314845fb2e611
Reviewed-on: https://go-review.googlesource.com/c/go/+/675077
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: avoid register clobber in s390x racecall
Michael Pratt [Wed, 21 May 2025 15:10:24 +0000 (11:10 -0400)]
runtime: avoid register clobber in s390x racecall

This is a regression in CL 643875. Loading gsignal clobbers R8, which
contains the m pointer needed for loading g0.

For #71395.

Change-Id: I6a6a636ca95442767efe0eb1b358f2139d18c5b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/675035
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agobufio: update buffer documentation
Lokesh Kumar [Wed, 21 May 2025 14:48:21 +0000 (14:48 +0000)]
bufio: update buffer documentation

Fixes #73778

Change-Id: If6d87a92786c9b0ee2bd790b57937919afe0fc5c
GitHub-Last-Rev: 4b4c7595d5779a127b01a5d71adca91cb5aa6c05
GitHub-Pull-Request: golang/go#73804
Reviewed-on: https://go-review.googlesource.com/c/go/+/674695
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
2 months agolib/fips140: set inprocess.txt to v1.0.0
Filippo Valsorda [Wed, 21 May 2025 12:41:28 +0000 (14:41 +0200)]
lib/fips140: set inprocess.txt to v1.0.0

Fixes #70200

Change-Id: I6a6a46567ce0834fb4b7f28bf06646326f8e5105
Reviewed-on: https://go-review.googlesource.com/c/go/+/674916
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/link: require cgo internal linking in TestIssue33979
Michael Pratt [Wed, 21 May 2025 14:58:32 +0000 (10:58 -0400)]
cmd/link: require cgo internal linking in TestIssue33979

This was a typo regression in CL 643897, which accidentally dropped the
requirement for cgo internal linking. As a result, this test is
continuously failing on windows-arm64.

For #71395.

Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: I6a6a636c25fd399cda6649ef94655aa112f10f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/675015
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocrypto/tls: replace custom intern cache with weak cache
Roland Shoemaker [Sat, 25 Jan 2025 18:28:02 +0000 (10:28 -0800)]
crypto/tls: replace custom intern cache with weak cache

Uses the new weak package to replace the existing custom intern cache
with a map of weak.Pointers instead. This simplifies the cache, and
means we don't need to store a slice of handles on the Conn anymore.

Change-Id: I5c2bf6ef35fac4255e140e184f4e48574b34174c
Reviewed-on: https://go-review.googlesource.com/c/go/+/644176
TryBot-Bypass: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>

2 months agoruntime: use cgroup CPU limit to set GOMAXPROCS
Michael Pratt [Mon, 5 May 2025 17:44:26 +0000 (13:44 -0400)]
runtime: use cgroup CPU limit to set GOMAXPROCS

This CL adds two related features enabled by default via compatibility
GODEBUGs containermaxprocs and updatemaxprocs.

On Linux, containermaxprocs makes the Go runtime consider cgroup CPU
bandwidth limits (quota/period) when setting GOMAXPROCS. If the cgroup
limit is lower than the number of logical CPUs available, then the
cgroup limit takes precedence.

On all OSes, updatemaxprocs makes the Go runtime periodically
recalculate the default GOMAXPROCS value and update GOMAXPROCS if it has
changed. If GOMAXPROCS is set manually, this update does not occur. This
is intended primarily to detect changes to cgroup limits, but it applies
on all OSes because the CPU affinity mask can change as well.

The runtime only considers the limit in the leaf cgroup (the one that
actually contains the process), caching the CPU limit file
descriptor(s), which are periodically reread for updates. This is a
small departure from the original proposed design. It will not consider
limits of parent cgroups (which may be lower than the leaf), and it will
not detection cgroup migration after process start.

We can consider changing this in the future, but the simpler approach is
less invasive; less risk to packages that have some awareness of runtime
internals. e.g., if the runtime periodically opens new files during
execution, file descriptor leak detection is difficult to implement in a
stable way.

For #73193.

Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I6a6a636c631c1ae577fb8254960377ba91c5dc98
Reviewed-on: https://go-review.googlesource.com/c/go/+/670497
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agointernal/runtime/cgroup: CPU cgroup limit discovery
Michael Pratt [Tue, 22 Apr 2025 10:24:37 +0000 (10:24 +0000)]
internal/runtime/cgroup: CPU cgroup limit discovery

For #73193.

Change-Id: I6a6a636ca9fa9cba429cf053468c56c2939cb1ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/668638
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agointernal/runtime/cgroup: add line-by-line reader using a single scratch buffer
Michael Pratt [Thu, 24 Apr 2025 09:20:30 +0000 (09:20 +0000)]
internal/runtime/cgroup: add line-by-line reader using a single scratch buffer

Change-Id: I6a6a636ca21edcc6f16705fbb72a5241d4f7f22d
Reviewed-on: https://go-review.googlesource.com/c/go/+/668637
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoos: add Root.MkdirAll
Damien Neil [Mon, 19 May 2025 20:09:06 +0000 (13:09 -0700)]
os: add Root.MkdirAll

For #67002

Change-Id: Idd74b5b59e787e89bdfad82171b6a7719465f501
Reviewed-on: https://go-review.googlesource.com/c/go/+/674116
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocrypto/sha1: add sha-ni AMD64 implementation
Roland Shoemaker [Sun, 19 Jan 2025 17:24:50 +0000 (09:24 -0800)]
crypto/sha1: add sha-ni AMD64 implementation

Based on the Intel docs. Provides a ~44% speed-up compared to the AVX
implementation and a ~57% speed-up compared to the generic AMD64
assembly implementation.

                    │ /usr/local/google/home/bracewell/sha1-avx.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │
                    │                     sec/op                      │            sec/op             vs base                │
Hash8Bytes/New-24                                        157.60n ± 0%                    92.51n ± 0%  -41.30% (p=0.000 n=20)
Hash8Bytes/Sum-24                                        147.00n ± 0%                    85.06n ± 0%  -42.14% (p=0.000 n=20)
Hash320Bytes/New-24                                       625.3n ± 0%                    276.7n ± 0%  -55.75% (p=0.000 n=20)
Hash320Bytes/Sum-24                                       626.2n ± 0%                    272.4n ± 0%  -56.51% (p=0.000 n=20)
Hash1K/New-24                                            1206.5n ± 0%                    692.2n ± 0%  -42.63% (p=0.000 n=20)
Hash1K/Sum-24                                            1210.0n ± 0%                    688.2n ± 0%  -43.13% (p=0.000 n=20)
Hash8K/New-24                                             7.744µ ± 0%                    4.920µ ± 0%  -36.46% (p=0.000 n=20)
Hash8K/Sum-24                                             7.737µ ± 0%                    4.913µ ± 0%  -36.50% (p=0.000 n=20)
geomean                                                   971.5n                         536.1n       -44.81%

                    │ /usr/local/google/home/bracewell/sha1-avx.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │
                    │                       B/s                       │             B/s              vs base                 │
Hash8Bytes/New-24                                        48.41Mi ± 0%                  82.47Mi ± 0%   +70.37% (p=0.000 n=20)
Hash8Bytes/Sum-24                                        51.90Mi ± 0%                  89.70Mi ± 0%   +72.82% (p=0.000 n=20)
Hash320Bytes/New-24                                      488.0Mi ± 0%                 1103.0Mi ± 0%  +126.01% (p=0.000 n=20)
Hash320Bytes/Sum-24                                      487.4Mi ± 0%                 1120.5Mi ± 0%  +129.91% (p=0.000 n=20)
Hash1K/New-24                                            809.6Mi ± 0%                 1410.8Mi ± 0%   +74.26% (p=0.000 n=20)
Hash1K/Sum-24                                            806.9Mi ± 0%                 1419.1Mi ± 0%   +75.86% (p=0.000 n=20)
Hash8K/New-24                                           1008.9Mi ± 0%                 1588.0Mi ± 0%   +57.40% (p=0.000 n=20)
Hash8K/Sum-24                                           1009.8Mi ± 0%                 1590.1Mi ± 0%   +57.47% (p=0.000 n=20)
geomean                                                  375.8Mi                       680.9Mi        +81.20%

                    │ /usr/local/google/home/bracewell/sha1-amd64.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │
                    │                      sec/op                       │            sec/op             vs base                │
Hash8Bytes/New-24                                          153.90n ± 0%                    92.51n ± 0%  -39.89% (p=0.000 n=20)
Hash8Bytes/Sum-24                                          145.90n ± 0%                    85.06n ± 0%  -41.70% (p=0.000 n=20)
Hash320Bytes/New-24                                         666.8n ± 0%                    276.7n ± 0%  -58.50% (p=0.000 n=20)
Hash320Bytes/Sum-24                                         660.3n ± 0%                    272.4n ± 0%  -58.75% (p=0.000 n=20)
Hash1K/New-24                                              1810.5n ± 0%                    692.2n ± 0%  -61.77% (p=0.000 n=20)
Hash1K/Sum-24                                              1806.0n ± 0%                    688.2n ± 0%  -61.90% (p=0.000 n=20)
Hash8K/New-24                                              13.509µ ± 0%                    4.920µ ± 0%  -63.58% (p=0.000 n=20)
Hash8K/Sum-24                                              13.515µ ± 0%                    4.913µ ± 0%  -63.65% (p=0.000 n=20)
geomean                                                     1.248µ                         536.1n       -57.05%

                    │ /usr/local/google/home/bracewell/sha1-amd64.bench │ /usr/local/google/home/bracewell/sha1-ni-stack.bench │
                    │                        B/s                        │             B/s              vs base                 │
Hash8Bytes/New-24                                          49.57Mi ± 0%                  82.47Mi ± 0%   +66.37% (p=0.000 n=20)
Hash8Bytes/Sum-24                                          52.29Mi ± 0%                  89.70Mi ± 0%   +71.52% (p=0.000 n=20)
Hash320Bytes/New-24                                        457.7Mi ± 0%                 1103.0Mi ± 0%  +140.97% (p=0.000 n=20)
Hash320Bytes/Sum-24                                        462.2Mi ± 0%                 1120.5Mi ± 0%  +142.45% (p=0.000 n=20)
Hash1K/New-24                                              539.4Mi ± 0%                 1410.8Mi ± 0%  +161.57% (p=0.000 n=20)
Hash1K/Sum-24                                              540.7Mi ± 0%                 1419.1Mi ± 0%  +162.44% (p=0.000 n=20)
Hash8K/New-24                                              578.4Mi ± 0%                 1588.0Mi ± 0%  +174.57% (p=0.000 n=20)
Hash8K/Sum-24                                              578.1Mi ± 0%                 1590.1Mi ± 0%  +175.07% (p=0.000 n=20)
geomean                                                    292.4Mi                       680.9Mi       +132.86%

Change-Id: Ife90386ba410a80c2e6222c1fe4df2368c4e12b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/642157
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Neal Patel <nealpatel@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: add valgrind instrumentation
Roland Shoemaker [Sat, 22 Mar 2025 00:58:55 +0000 (00:58 +0000)]
runtime: add valgrind instrumentation

Add build tag gated Valgrind annotations to the runtime which let it
understand how the runtime manages memory. This allows for Go binaries
to be run under Valgrind without emitting spurious errors.

Instead of adding the Valgrind headers to the tree, and using cgo to
call the various Valgrind client request macros, we just add an assembly
function which emits the necessary instructions to trigger client
requests.

In particular we add instrumentation of the memory allocator, using a
two-level mempool structure (as described in the Valgrind manual [0]).
We also add annotations which allow Valgrind to track which memory we
use for stacks, which seems necessary to let it properly function.

We describe the memory model to Valgrind as follows: we treat heap
arenas as a "pool" created with VALGRIND_CREATE_MEMPOOL_EXT (so that we
can use VALGRIND_MEMPOOL_METAPOOL and VALGRIND_MEMPOOL_AUTO_FREE).
Within the pool we treat spans as "superblocks", annotated with
VALGRIND_MEMPOOL_ALLOC. We then allocate individual objects within spans
with VALGRIND_MALLOCLIKE_BLOCK.

It should be noted that running binaries under Valgrind can be _quite
slow_, and certain operations, such as running the GC, can be _very
slow_. It is recommended to run programs with GOGC=off. Additionally,
async preemption should be turned off, since it'll cause strange
behavior (GODEBUG=asyncpreemptoff=1).

Running Valgrind with --leak-check=yes will result in some errors
resulting from some things not being marked fully free'd. These likely
need more annotations to rectify, but for now it is recommended to run
with --leak-check=off.

Updates #73602

[0] https://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools

Change-Id: I71b26c47d7084de71ef1e03947ef6b1cc6d38301
Reviewed-on: https://go-review.googlesource.com/c/go/+/674077
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agocmd/doc: allow go doc -http without package in current directory
Michael Matloob [Wed, 21 May 2025 16:18:03 +0000 (12:18 -0400)]
cmd/doc: allow go doc -http without package in current directory

go doc tries to find a package to display documentation for. In the case
that no package is provided, it uses "." just like go list does. So if
go doc -http is run without any arguments, it tries to show the
documentation for the package in the current directory. As a special
case, if no arguments are provided, allow no package to match the
current directory and just open the root pkgsite page.

For #68106

Change-Id: I6d65b160a838591db953fac630eced6b09106877
Reviewed-on: https://go-review.googlesource.com/c/go/+/675075
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: guarantee checkfinalizers test allocates in a shared tiny block
Michael Anthony Knyszek [Tue, 20 May 2025 20:26:56 +0000 (20:26 +0000)]
runtime: guarantee checkfinalizers test allocates in a shared tiny block

Currently the checkfinalizers test (TestDetectCleanupOrFinalizerLeak)
only *tries* to ensure the tiny alloc with a cleanup attached shares a
block with other objects. However, what it does is insufficient, because
it could get unlucky and have the last object allocated be the first
object of a new block.

This change changes the test to guarantee that a tiny object is not at
the start of a fresh block by looking at the alignment of the object's
pointer. If the object's pointer is odd, then that's good enough to know
that it shares a block with something else, since the blocks themselves
are aligned to a much higher power of two.

This fixes a failure I've seen on the builders.

Fixes #73810.

Change-Id: Ieafdbb9cccb0d2dc3659a9a5d9d9233718461635
Reviewed-on: https://go-review.googlesource.com/c/go/+/674655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2 months agoos: add Root.RemoveAll
Damien Neil [Fri, 28 Mar 2025 23:40:34 +0000 (16:40 -0700)]
os: add Root.RemoveAll

For #67002

Change-Id: If59dab4fd934a115d8ff383826525330de750b54
Reviewed-on: https://go-review.googlesource.com/c/go/+/661595
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>

2 months agointernal/pkgbits: specify that RelIdx is an element index
Mark Freeman [Tue, 20 May 2025 18:33:03 +0000 (14:33 -0400)]
internal/pkgbits: specify that RelIdx is an element index

Without this, it's not clear what this is relative to or the
granularity of the index.

Change-Id: Ibaabe47e089f0ba9b084523969c5347ed4c9dbee
Reviewed-on: https://go-review.googlesource.com/c/go/+/674636
Auto-Submit: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile: add rules about ORN and ANDN
Xiaolin Zhao [Tue, 20 May 2025 02:28:17 +0000 (10:28 +0800)]
cmd/compile: add rules about ORN and ANDN

Reduce the number of go toolchain instructions on loong64 as follows.

    file      before    after     Δ       %
    addr2line 279880    279776  -104   -0.0372%
    asm       556638    556410  -228   -0.0410%
    buildid   272272    272072  -200   -0.0735%
    cgo       481522    481318  -204   -0.0424%
    compile   2457788   2457580 -208   -0.0085%
    covdata   323384    323280  -104   -0.0322%
    cover     518450    518234  -216   -0.0417%
    dist      340790    340686  -104   -0.0305%
    distpack  282456    282252  -204   -0.0722%
    doc       789932    789688  -244   -0.0309%
    fix       324332    324228  -104   -0.0321%
    link      704622    704390  -232   -0.0329%
    nm        277132    277028  -104   -0.0375%
    objdump   507862    507758  -104   -0.0205%
    pack      221774    221674  -100   -0.0451%
    pprof     1469816   1469552 -264   -0.0180%
    test2json 254836    254732  -104   -0.0408%
    trace     1100002   1099738 -264   -0.0240%
    vet       781078    780874  -204   -0.0261%
    go        1529116   1528848 -268   -0.0175%
    gofmt     318556    318448  -108   -0.0339%
    total     13792238 13788566 -3672  -0.0266%

Change-Id: I23fb3ebd41309252c7075e57ea7094e79f8c4fef
Reviewed-on: https://go-review.googlesource.com/c/go/+/674335
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
2 months agocmd/internal/obj/loong64: remove unused register alias definitions
Guoqi Chen [Thu, 16 Nov 2023 09:28:46 +0000 (17:28 +0800)]
cmd/internal/obj/loong64: remove unused register alias definitions

Change-Id: Ie788747372cd47cb3780e75b35750bb08bd166fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/542835
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agointernal/pkgbits: indent productions and hoist some types up
Mark Freeman [Mon, 19 May 2025 22:00:31 +0000 (18:00 -0400)]
internal/pkgbits: indent productions and hoist some types up

The types being hoisted are those which cannot be referenced; that is,
where Ref[T] is illegal. These are most clearly owned by pkgbits. The
types which follow are those which can be referenced.

Referenceable types are more hazy due to the reference mechanism of UIR
- sections. These are a detail of the UIR file format and are surfaced
directly to importers.

I suspect that pkgbits would benefit from a reference mechanism not
dependent on sections. This would permit us to push down many types
from the noder into pkgbits, reducing the interface surface without
giving up deduplication.

Change-Id: Ifaf5cd9de20c767ad0941413385b308d628aac6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674635
Auto-Submit: Mark Freeman <mark@golang.org>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
2 months agointernal/trace: add generator tests for sync events
Felix Geisendörfer [Fri, 28 Feb 2025 16:30:54 +0000 (17:30 +0100)]
internal/trace: add generator tests for sync events

Add generator tests that verify the timestamps for the sync events
emitted in the go1.25 trace format and earlier versions.

Add the ability to configure the properties of the per-generation sync
batches in testgen. Also refactor testgen to produce more realistic
timestamps by keeping track of lastTs and using it for structural
batches that don't have their own timestamps. Otherwise they default to
zero which means the minTs of the generation can't be controlled.

For #69869

Change-Id: I92a49b8281bc4169b63e13c030c1de7720cd6f26
Reviewed-on: https://go-review.googlesource.com/c/go/+/653876
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agointernal/trace/internal/testgen: make generated trace version configurable
Felix Geisendörfer [Fri, 28 Feb 2025 16:28:43 +0000 (17:28 +0100)]
internal/trace/internal/testgen: make generated trace version configurable

Replace hard coded references to version.Go122 with the trace version
passed to NewTrace. This allows writing testgen tests for newer trace
versions.

For #69869

Change-Id: Id25350cea1c397a09ca23465526ff259e34a4752
Reviewed-on: https://go-review.googlesource.com/c/go/+/653875
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agointernal/trace: add a validator test for the new clock snapshots
Felix Geisendörfer [Sat, 3 May 2025 12:56:23 +0000 (15:56 +0300)]
internal/trace: add a validator test for the new clock snapshots

Check that the clock snapshots, when expected to be present, are
non-zero and monotonically increasing.

This required some refactoring to make the validator aware of the
version of the trace it is validating.

Change-Id: I04c4dd10fe6975cbac12bb0ddaebcec3a5284e7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/669715
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
2 months agointernal/trace: expose clock snapshot timestamps on sync event
Felix Geisendörfer [Fri, 28 Feb 2025 15:07:45 +0000 (16:07 +0100)]
internal/trace: expose clock snapshot timestamps on sync event

Add ClockSnapshot field to the Sync event type and populate it with the
information from the new EvClockSnapshot event when available.

For #69869

Change-Id: I3b24b5bfa15cc7a7dba270f5e6bf189adb096840
Reviewed-on: https://go-review.googlesource.com/c/go/+/653576
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

2 months agoruntime,internal/trace: emit clock snapshots at the start of trace generations
Felix Geisendörfer [Fri, 28 Feb 2025 15:07:16 +0000 (16:07 +0100)]
runtime,internal/trace: emit clock snapshots at the start of trace generations

Replace the per-generation EvEventBatch containing a lone EvFrequency
event with a per-generation EvEventBatch containing a EvSync header
followed by an EvFrequency and EvClockSnapshot event.

The new EvClockSnapshot event contains trace, mono and wall clock
snapshots taken in close time proximity. Ignoring minor resolution
differences, the trace and mono clock are the same on linux, but not on
windows (which still uses a TSC based trace clock).

Emit the new sync batch at the very beginning of every new generation
rather than the end to be in harmony with the internal/trace reader
which emits a sync event at the beginning of every generation as well
and guarantees monotonically increasing event timestamps.

Bump the version of the trace file format to 1.25 since this change is
not backwards compatible.

Update the internal/trace reader implementation to decode the new
events, but do not expose them to the public reader API yet. This is
done in the next CL.

For #69869

Change-Id: I5bfedccdd23dc0adaf2401ec0970cbcc32363393
Reviewed-on: https://go-review.googlesource.com/c/go/+/653575
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agocmd/internal/obj/riscv: fix vector integer multiply add
Mark Ryan [Tue, 6 May 2025 12:07:09 +0000 (14:07 +0200)]
cmd/internal/obj/riscv: fix vector integer multiply add

The RISC-V integer vector multiply add instructions are not encoded
correctly; the first and second arguments are swapped. For example,
the instruction

VMACCVV V1, V2, V3

encodes to

b620a1d7 or vmacc.vv v3,v1,v2

and not

b61121d7 or vmacc.vv v3,v2,v1

as expected.

This is inconsistent with the argument ordering we use for 3
argument vector instructions, in which the argument order, as given
in the RISC-V specifications, is reversed, and also with the vector
FMA instructions which have the same argument ordering as the vector
integer multiply add instructions in the "The RISC-V Instruction Set
Manual Volume I". For example, in the ISA manual we have the
following instruction definitions

; Integer multiply-add, overwrite addend
vmacc.vv vd, vs1, vs2, vm    # vd[i] = +(vs1[i] * vs2[i]) + vd[i]

; FP multiply-accumulate, overwrites addend
vfmacc.vv vd, vs1, vs2, vm    # vd[i] = +(vs1[i] * vs2[i]) + vd[i]

It's reasonable to expect that the Go assembler would use the same
argument ordering for both of these instructions. It currently does
not.

We fix the issue by switching the argument ordering for the vector
integer multiply add instructions to match those of the vector FMA
instructions.

Change-Id: Ib98e9999617f991969e5c831734b3bb3324439f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/670335
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2 months agoos: skip TestOpenFileCreateExclDanglingSymlink when no symlinks
Damien Neil [Wed, 21 May 2025 00:02:11 +0000 (17:02 -0700)]
os: skip TestOpenFileCreateExclDanglingSymlink when no symlinks

Skip this test on plan9, and any other platform that doesn't
have symlinks.

Fixes #73729

Change-Id: I8052db24ed54c3361530bd4f54c96c9d10c4714c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674697
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
2 months agoruntime, internal/fuzz: optimize build tag combination on loong64
Guoqi Chen [Fri, 25 Apr 2025 11:59:01 +0000 (19:59 +0800)]
runtime, internal/fuzz: optimize build tag combination on loong64

Change-Id: I971b789beb08e0c6b11169fd5547a8d4ab74fab5
Reviewed-on: https://go-review.googlesource.com/c/go/+/668155
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2 months agocrypto/subtle: optimize function xorBytes using SIMD on loong64
Xiaolin Zhao [Fri, 16 May 2025 03:05:03 +0000 (11:05 +0800)]
crypto/subtle: optimize function xorBytes using SIMD on loong64

On the Loongson-3A6000-HV and Loongson-3A5000, there has been
a significant improvement in all performance metrics except
for '8Bytes', which has experienced a decline, as follows.

goos: linux
goarch: loong64
pkg: crypto/subtle
cpu: Loongson-3A6000-HV @ 2500.00MHz
                                   |  bench.old   |              bench.new              |
                                   |    sec/op    |   sec/op     vs base                |
XORBytes/8Bytes                       7.282n ± 0%   8.805n ± 0%  +20.91% (p=0.000 n=10)
XORBytes/128Bytes                     14.43n ± 0%   10.01n ± 0%  -30.63% (p=0.000 n=10)
XORBytes/2048Bytes                   110.60n ± 0%   46.57n ± 0%  -57.89% (p=0.000 n=10)
XORBytes/8192Bytes                    418.7n ± 0%   161.8n ± 0%  -61.36% (p=0.000 n=10)
XORBytes/32768Bytes                   3.220µ ± 0%   1.673µ ± 0%  -48.04% (p=0.000 n=10)
XORBytesAlignment/8Bytes0Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes1Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes2Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes3Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes4Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes5Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes6Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/8Bytes7Offset       7.621n ± 0%   9.305n ± 0%  +22.10% (p=0.000 n=10)
XORBytesAlignment/128Bytes0Offset    14.430n ± 0%   9.973n ± 0%  -30.88% (p=0.000 n=10)
XORBytesAlignment/128Bytes1Offset     20.83n ± 0%   11.03n ± 0%  -47.05% (p=0.000 n=10)
XORBytesAlignment/128Bytes2Offset     20.83n ± 0%   11.03n ± 0%  -47.07% (p=0.000 n=10)
XORBytesAlignment/128Bytes3Offset     20.83n ± 0%   11.03n ± 0%  -47.07% (p=0.000 n=10)
XORBytesAlignment/128Bytes4Offset     20.83n ± 0%   11.03n ± 0%  -47.05% (p=0.000 n=10)
XORBytesAlignment/128Bytes5Offset     20.83n ± 0%   11.03n ± 0%  -47.05% (p=0.000 n=10)
XORBytesAlignment/128Bytes6Offset     20.83n ± 0%   11.03n ± 0%  -47.05% (p=0.000 n=10)
XORBytesAlignment/128Bytes7Offset     20.83n ± 0%   11.03n ± 0%  -47.05% (p=0.000 n=10)
XORBytesAlignment/2048Bytes0Offset   110.60n ± 0%   46.82n ± 0%  -57.67% (p=0.000 n=10)
XORBytesAlignment/2048Bytes1Offset    234.4n ± 0%   109.3n ± 0%  -53.37% (p=0.000 n=10)
XORBytesAlignment/2048Bytes2Offset    234.4n ± 0%   109.3n ± 0%  -53.37% (p=0.000 n=10)
XORBytesAlignment/2048Bytes3Offset    234.4n ± 0%   109.3n ± 0%  -53.37% (p=0.000 n=10)
XORBytesAlignment/2048Bytes4Offset    234.5n ± 0%   109.3n ± 0%  -53.39% (p=0.000 n=10)
XORBytesAlignment/2048Bytes5Offset    234.4n ± 0%   109.3n ± 0%  -53.37% (p=0.000 n=10)
XORBytesAlignment/2048Bytes6Offset    234.4n ± 0%   109.3n ± 0%  -53.37% (p=0.000 n=10)
XORBytesAlignment/2048Bytes7Offset    234.5n ± 0%   109.3n ± 0%  -53.39% (p=0.000 n=10)
geomean                               39.42n        26.00n       -34.05%

goos: linux
goarch: loong64
pkg: crypto/subtle
cpu: Loongson-3A5000 @ 2500.00MHz
                                   |  bench.old   |              bench.new              |
                                   |    sec/op    |   sec/op     vs base                |
XORBytes/8Bytes                       11.21n ± 0%   12.41n ± 1%  +10.70% (p=0.000 n=10)
XORBytes/128Bytes                     18.22n ± 0%   13.61n ± 0%  -25.30% (p=0.000 n=10)
XORBytes/2048Bytes                   162.20n ± 0%   48.46n ± 0%  -70.13% (p=0.000 n=10)
XORBytes/8192Bytes                    629.8n ± 0%   163.8n ± 0%  -73.99% (p=0.000 n=10)
XORBytes/32768Bytes                  4731.0n ± 1%   632.8n ± 0%  -86.63% (p=0.000 n=10)
XORBytesAlignment/8Bytes0Offset       11.61n ± 1%   12.42n ± 0%   +6.98% (p=0.000 n=10)
XORBytesAlignment/8Bytes1Offset       11.61n ± 0%   12.41n ± 0%   +6.89% (p=0.000 n=10)
XORBytesAlignment/8Bytes2Offset       11.61n ± 0%   12.42n ± 0%   +6.98% (p=0.000 n=10)
XORBytesAlignment/8Bytes3Offset       11.61n ± 0%   12.41n ± 0%   +6.89% (p=0.000 n=10)
XORBytesAlignment/8Bytes4Offset       11.61n ± 0%   12.42n ± 0%   +6.98% (p=0.000 n=10)
XORBytesAlignment/8Bytes5Offset       11.61n ± 0%   12.41n ± 0%   +6.89% (p=0.000 n=10)
XORBytesAlignment/8Bytes6Offset       11.61n ± 0%   12.41n ± 1%   +6.89% (p=0.000 n=10)
XORBytesAlignment/8Bytes7Offset       11.61n ± 0%   12.42n ± 0%   +6.98% (p=0.000 n=10)
XORBytesAlignment/128Bytes0Offset     17.82n ± 0%   13.62n ± 0%  -23.57% (p=0.000 n=10)
XORBytesAlignment/128Bytes1Offset     26.62n ± 0%   18.43n ± 0%  -30.78% (p=0.000 n=10)
XORBytesAlignment/128Bytes2Offset     26.64n ± 0%   18.43n ± 0%  -30.85% (p=0.000 n=10)
XORBytesAlignment/128Bytes3Offset     26.65n ± 0%   18.42n ± 0%  -30.90% (p=0.000 n=10)
XORBytesAlignment/128Bytes4Offset     26.65n ± 0%   18.42n ± 0%  -30.88% (p=0.000 n=10)
XORBytesAlignment/128Bytes5Offset     26.62n ± 0%   18.42n ± 0%  -30.82% (p=0.000 n=10)
XORBytesAlignment/128Bytes6Offset     26.63n ± 0%   18.42n ± 0%  -30.84% (p=0.000 n=10)
XORBytesAlignment/128Bytes7Offset     26.64n ± 0%   18.42n ± 0%  -30.86% (p=0.000 n=10)
XORBytesAlignment/2048Bytes0Offset   161.80n ± 0%   48.25n ± 0%  -70.18% (p=0.000 n=10)
XORBytesAlignment/2048Bytes1Offset    354.6n ± 0%   189.2n ± 0%  -46.64% (p=0.000 n=10)
XORBytesAlignment/2048Bytes2Offset    354.6n ± 0%   189.2n ± 0%  -46.64% (p=0.000 n=10)
XORBytesAlignment/2048Bytes3Offset    354.7n ± 0%   189.2n ± 0%  -46.66% (p=0.000 n=10)
XORBytesAlignment/2048Bytes4Offset    354.7n ± 0%   189.2n ± 1%  -46.66% (p=0.000 n=10)
XORBytesAlignment/2048Bytes5Offset    354.7n ± 0%   189.2n ± 0%  -46.66% (p=0.000 n=10)
XORBytesAlignment/2048Bytes6Offset    354.7n ± 0%   189.2n ± 0%  -46.66% (p=0.000 n=10)
XORBytesAlignment/2048Bytes7Offset    354.8n ± 0%   189.2n ± 0%  -46.67% (p=0.000 n=10)
geomean                               56.46n        36.46n       -35.42%

Change-Id: I66e150b132517e9ff4827abf796812ffe608c052
Reviewed-on: https://go-review.googlesource.com/c/go/+/673355
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2 months agocmd/dist, internal/platform: enable internal linking feature and test on loong64
limeidan [Mon, 9 Oct 2023 09:32:03 +0000 (17:32 +0800)]
cmd/dist, internal/platform: enable internal linking feature and test on loong64

Change-Id: Ifea676e9eb44281465832fc4050f6286e50f4543
Reviewed-on: https://go-review.googlesource.com/c/go/+/533717
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: Qiqi Huang <huangqiqi@loongson.cn>
2 months agocmd/compile: fix the implementation of NORconst on loong64
Xiaolin Zhao [Mon, 19 May 2025 09:02:48 +0000 (17:02 +0800)]
cmd/compile: fix the implementation of NORconst on loong64

In the loong64 instruction set, there is no NORI instruction,
so the immediate value in NORconst need to be stored in register
and then use the three-register NOR instruction.

Change-Id: I5ef697450619317218cb3ef47fc07e238bdc2139
Reviewed-on: https://go-review.googlesource.com/c/go/+/673836
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile/internal/escape: improve order of work to speed up analyzing many locations
thepudds [Wed, 12 Mar 2025 21:29:25 +0000 (17:29 -0400)]
cmd/compile/internal/escape: improve order of work to speed up analyzing many locations

For the package github.com/microsoft/typescript-go/internal/checker,
compilation currently spends most of its time in escape analysis.

Here, we re-order work to be more efficient when analyzing many
locations, and delay visiting some locations to prioritize locations
that might be more likely to reach a terminal point of reaching the
heap and possibly reduce the count of intermediate states for each location.

Action graph reported build times show roughly a 5x improvement for
compilation of the typescript-go/internal/checker package:

  go1.24.0:      91.792s
  cl-657179-ps1: 17.578s

with timing via:

  go build -a -debug-actiongraph=/tmp/actiongraph-cl-657179-ps1 -v github.com/microsoft/typescript-go/internal/checker

There are some additional adjustments to make here, including we can
consider a follow-on CL I have that parallelizes the operations of the
core loop, but this seems to be a nice win as is, and my understanding
is the desire is to merge this as it stands.

Updates #72815

Change-Id: I1753c5354b495b059f68fb97f3103ee7834f9eee
Reviewed-on: https://go-review.googlesource.com/c/go/+/657179
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoreflect: turn off allocation test if instrumentation is on
khr@golang.org [Tue, 20 May 2025 22:59:02 +0000 (15:59 -0700)]
reflect: turn off allocation test if instrumentation is on

Help fix the asan builders.

Change-Id: I980f5171519643c3543bdefc6ea46fd0fca17c28
Reviewed-on: https://go-review.googlesource.com/c/go/+/674616
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2 months agoruntime: disable stack allocation test when instrumentation is on
khr@golang.org [Tue, 20 May 2025 22:56:29 +0000 (15:56 -0700)]
runtime: disable stack allocation test when instrumentation is on

Should fix some asan build failures.

Change-Id: Ic0a816b56a1a278aa0ad541aea962f9fea7b10fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/674696
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2 months agocrypto/ecdsa,crypto/ed25519: cache FIPS private keys
Filippo Valsorda [Wed, 8 Jan 2025 10:16:48 +0000 (11:16 +0100)]
crypto/ecdsa,crypto/ed25519: cache FIPS private keys

All private keys need to go through a slow PCT in FIPS-140 mode.

ECDH and RSA keys have places to hide a precomputed value without
causing races, but Ed25519 and ECDSA keys might be constructed by the
application and then used with concurrent Sign calls.

For these, implement an equivalent to crypto/internal/boring/bcache
using weak.Pointer and runtime.AddCleanup.

fips140: latest
goos: linux
goarch: amd64
pkg: crypto/ed25519
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
           │ 1a93e4a2cf  │             78a819ea78             │
           │   sec/op    │   sec/op     vs base               │
Signing-16   72.72µ ± 0%   16.93µ ± 1%  -76.72% (p=0.002 n=6)

fips140: off
goos: linux
goarch: amd64
pkg: crypto/ed25519
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
           │ 310bad31e5  │         310bad31e5-dirty          │
           │   sec/op    │   sec/op     vs base              │
Signing-16   17.18µ ± 1%   16.95µ ± 1%  -1.36% (p=0.002 n=6)

fips140: latest
goos: linux
goarch: amd64
pkg: crypto/ecdsa
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
             │  1a93e4a2cf  │             78a819ea78             │
             │    sec/op    │   sec/op     vs base               │
Sign/P256-16    90.97µ ± 0%   21.04µ ± 0%  -76.87% (p=0.002 n=6)
Sign/P384-16    701.6µ ± 1%   142.0µ ± 0%  -79.75% (p=0.002 n=6)
Sign/P521-16   2943.5µ ± 1%   491.9µ ± 0%  -83.29% (p=0.002 n=6)

fips140: off
goos: linux
goarch: amd64
pkg: crypto/ecdsa
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
             │ 1a93e4a2cf  │             78a819ea78             │
             │   sec/op    │   sec/op     vs base               │
Sign/P256-16   21.27µ ± 0%   21.13µ ± 0%   -0.65% (p=0.002 n=6)
Sign/P384-16   143.3µ ± 0%   142.4µ ± 0%   -0.63% (p=0.009 n=6)
Sign/P521-16   525.3µ ± 0%   462.1µ ± 0%  -12.04% (p=0.002 n=6)

This unavoidably introduces allocations in the very first use of Ed25519
private keys, but usually that's not in the hot path.

Change-Id: I6a6a465640a5dff64edd73ee5dda5f2ad1b476b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/654096
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: record synctest bubble ownership in hchan
Damien Neil [Tue, 20 May 2025 18:16:23 +0000 (11:16 -0700)]
runtime: record synctest bubble ownership in hchan

Replace the hchan.synctest bool with an hchan.bubble reference
to the synctest bubble that created the chan. I originally used
a bool to avoid increasing the size of hchan, but we have space
in hchan's current size class for another pointer.

This lets us detect one bubble operating on a chan created
in a different bubble.

For #67434

Change-Id: If6cf9ffcb372fe7fb3f8f4ef27b664848578ba5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Damien Neil <dneil@google.com>

2 months agoencoding/json: avoid supurious synctest deadlock detection
Damien Neil [Thu, 15 May 2025 18:03:15 +0000 (11:03 -0700)]
encoding/json: avoid supurious synctest deadlock detection

Use a sync.OnceValue rather than a sync.WaitGroup to
coordinate access to encoderCache entries.

The OnceValue better expresses the intent of the code
(we want to initialize the cache entry only once).

However, the motivation for this change is to avoid
testing/synctest incorrectly reporting a deadlock
when multiple bubbles call Marshal at the same time.
Goroutines blocked on WaitGroup.Wait are "durably blocked",
causing confusion when a goroutine in one bubble Waits
for a goroutine in a different bubble. Goroutines blocked
on OnceValue are not durably blocked, avoiding the problem.

Fixes #73733
For #67434

Change-Id: I81cddda80af67cf5c280fd4327620bc37e7a6fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/673335
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agotesting/synctest: add Test
Damien Neil [Mon, 12 May 2025 18:15:08 +0000 (11:15 -0700)]
testing/synctest: add Test

Add a synctest.Test function, superseding the experimental
synctest.Run function. Promote the testing/synctest package
out of experimental status.

For #67434
For #73567

Change-Id: I3c5ba030860d90fe2ddb517a2f3536efd60181a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/671961
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2 months agocmd/doc: use golang.org/x/pkgsite/cmd/internal/doc to start server
Michael Matloob [Mon, 19 May 2025 19:31:37 +0000 (15:31 -0400)]
cmd/doc: use golang.org/x/pkgsite/cmd/internal/doc to start server

This change switches the pkgsite command invoked to start a pkgsite
server from golang.org/x/pkgsite/cmd/pkgsite to
golang.org/x/pkgsite/cmd/internal/doc. The doc command is a simplified
version of cmd/pkgsite that changes some options to improve the user
experience. For example, it limits logging informational log messages,
doesn't always expect to find modules (for example if we're outside of a
module getting documentation for the standard library), and it takes the
address of the page to open in the browser (which simplifies waiting for
the server to start listening).

Fixes #68106

Change-Id: I667a49d03823242fa1aff333ecb1c0f198e92412
Reviewed-on: https://go-review.googlesource.com/c/go/+/674158
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: David Chase <drchase@google.com>
2 months agocmd/doc: use go list to determine import path if it's missing
Michael Matloob [Mon, 19 May 2025 19:31:37 +0000 (15:31 -0400)]
cmd/doc: use go list to determine import path if it's missing

cmd/doc uses go/build to get information about the packages it's
documenting. In some cases, go/build can return a build.Package that it
couldn't determine an import path for, in which case it sets the import
path to ".". This can happen for relative package paths in in a module:
for relative package paths we don't use the go command to get
information about the module and just open the source files directly
instead, and will be missing the import path. This is usually okay
because go doc doesn't need to print the import path of the package it's
documenting, but for go doc -http, we want to know the import path so we
can open the right page in the browser.

For #68106

Change-Id: Ifba92862ad01d8d63f531c2451f18db2b0d7a3e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/674556
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
2 months agocmd/doc: show page for the requested object
Michael Matloob [Mon, 19 May 2025 19:31:37 +0000 (15:31 -0400)]
cmd/doc: show page for the requested object

This fixes a bug where we start pkgsite for every requested object,
rather than the one that we would have printed the documentation for.
To make things simple, we'll run the logic that prints the
documentation, but with an io.Discard writer. Then we can tell if the
documentation was found based on the return values of those functions.

For #68106

Change-Id: Ibf2ab1720f381d7214fc9239b9c2e915c91f7f7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/674555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
2 months agocmd/compile: memcombine different size stores
Junyang Shao [Mon, 31 Mar 2025 17:50:10 +0000 (17:50 +0000)]
cmd/compile: memcombine different size stores

This CL implements the TODO in combineStores to allow combining
stores of different sizes, as long as the total size aligns to
2, 4, 8.

Fixes #72832.

Change-Id: I6d1d471335da90d851ad8f3b5a0cf10bdcfa17c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/661855
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agointernal/pkgbits: rename RelocEnt to RefTableEntry
Mark Freeman [Mon, 19 May 2025 20:06:42 +0000 (16:06 -0400)]
internal/pkgbits: rename RelocEnt to RefTableEntry

Change-Id: I9b1c9a0499ad3444e8cb3e4be187f9fab816c90c
Reviewed-on: https://go-review.googlesource.com/c/go/+/674159
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <mark@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile/internal/noder: mark Ref[T] as a primitive
Mark Freeman [Mon, 19 May 2025 19:51:03 +0000 (15:51 -0400)]
cmd/compile/internal/noder: mark Ref[T] as a primitive

Like Sync, Ref[T] is also used to define things like StringRef.

Change-Id: I9e10234504ee4dd03907bb058a6f3ae7e6a287ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/674157
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Bypass: Mark Freeman <mark@golang.org>
Auto-Submit: Mark Freeman <mark@golang.org>

2 months agoreflect: add TypeAssert[T]
Mateusz Poliwczak [Tue, 20 May 2025 15:39:22 +0000 (15:39 +0000)]
reflect: add TypeAssert[T]

This implementation is zero-alloc when T is a concrete type,
allocates when val contains a method or when T is a interface
and Value was obtained for example through Elem(), in which case
it has to be allocated to avoid sharing the same memory.

goos: linux
goarch: amd64
pkg: reflect
cpu: AMD Ryzen 5 4600G with Radeon Graphics
                                                                         │ /tmp/bench2 │
                                                                         │   sec/op    │
TypeAssert/TypeAssert[int](int)-12                                         2.725n ± 1%
TypeAssert/TypeAssert[uint8](int)-12                                       2.599n ± 1%
TypeAssert/TypeAssert[fmt.Stringer](reflect_test.testTypeWithMethod)-12    8.470n ± 0%
TypeAssert/TypeAssert[fmt.Stringer](*reflect_test.testTypeWithMethod)-12   8.460n ± 1%
TypeAssert/TypeAssert[interface_{}](int)-12                                4.181n ± 1%
TypeAssert/TypeAssert[interface_{}](reflect_test.testTypeWithMethod)-12    4.178n ± 1%
TypeAssert/TypeAssert[time.Time](time.Time)-12                             2.839n ± 0%
TypeAssert/TypeAssert[func()_string](func()_string)-12                     151.1n ± 1%
geomean                                                                    6.645n

                                                                         │ /tmp/bench2  │
                                                                         │     B/op     │
TypeAssert/TypeAssert[int](int)-12                                         0.000 ± 0%
TypeAssert/TypeAssert[uint8](int)-12                                       0.000 ± 0%
TypeAssert/TypeAssert[fmt.Stringer](reflect_test.testTypeWithMethod)-12    0.000 ± 0%
TypeAssert/TypeAssert[fmt.Stringer](*reflect_test.testTypeWithMethod)-12   0.000 ± 0%
TypeAssert/TypeAssert[interface_{}](int)-12                                0.000 ± 0%
TypeAssert/TypeAssert[interface_{}](reflect_test.testTypeWithMethod)-12    0.000 ± 0%
TypeAssert/TypeAssert[time.Time](time.Time)-12                             0.000 ± 0%
TypeAssert/TypeAssert[func()_string](func()_string)-12                     72.00 ± 0%
geomean                                                                               ¹

Fixes #62121

Change-Id: I0911c70c5966672c930d387438643f94a40441c4
GitHub-Last-Rev: ce89a53097b53fc59ff3ce3996917f8484ad3967
GitHub-Pull-Request: golang/go#71639
Reviewed-on: https://go-review.googlesource.com/c/go/+/648056
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2 months agoruntime: disallow closing bubbled chans from outside bubble
Damien Neil [Fri, 9 May 2025 23:18:49 +0000 (16:18 -0700)]
runtime: disallow closing bubbled chans from outside bubble

A chan created within a synctest bubble may not be
operated on from outside the bubble.
We panicked on send and receive, but not close.
Panic on close as well.

For #67434

Change-Id: I98d39e0cf7baa1a679aca1fb325453d69c535308
Reviewed-on: https://go-review.googlesource.com/c/go/+/671960
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Damien Neil <dneil@google.com>

2 months agoruntime: print blocking status of bubbled goroutines in stacks
Damien Neil [Fri, 9 May 2025 18:07:14 +0000 (11:07 -0700)]
runtime: print blocking status of bubbled goroutines in stacks

For goroutines in a synctest bubble, include whether the goroutine
is "durably blocked" or not in the goroutine status.

Synctest categorizes goroutines in certain states as "durably"
blocked, where the goroutine is not merely idle but can only
be awoken by another goroutine in its bubble. To make it easier
for users to understand why a bubble is or is not idle,
print the state of each bubbled goroutine.

For example:

  goroutine 36 [chan receive, synctest bubble 34, not durably blocked]:
  goroutine 37 [chan receive (synctest), synctest bubble 34, durably blocked]:

Goroutine 36 is receiving from a channel created outside its bubble.
Goroutine 36 is receiving from a channel created inside its bubble.

For #67434

Change-Id: I006b656a9ce7eeb75b2be21e748440a5dd57ceb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/670976
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2 months agodoc: add release notes for cleanups and the unique package
Michael Anthony Knyszek [Fri, 9 May 2025 19:45:25 +0000 (19:45 +0000)]
doc: add release notes for cleanups and the unique package

For #71661.

Change-Id: I74870de3f17a938bc9fd83ccc41e13e64b55b5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/671438
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
2 months agoruntime: add package doc for checkfinalizer mode
Michael Anthony Knyszek [Wed, 2 Apr 2025 01:46:45 +0000 (01:46 +0000)]
runtime: add package doc for checkfinalizer mode

Fixes #72949.

Change-Id: I114eda73c57bc7d596eb1656e738b80c1cbe5254
Reviewed-on: https://go-review.googlesource.com/c/go/+/662039
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: report finalizer and cleanup queue length with checkfinalizer>0
Michael Anthony Knyszek [Fri, 9 May 2025 19:33:22 +0000 (19:33 +0000)]
runtime: report finalizer and cleanup queue length with checkfinalizer>0

This change adds tracking for approximate finalizer and cleanup queue
lengths. These lengths are reported once every GC cycle as a single line
printed to stderr when GODEBUG=checkfinalizer>0.

This change lays the groundwork for runtime/metrics metrics to produce
the same values.

For #72948.
For #72950.

Change-Id: I081721238a0fc4c7e5bee2dbaba6cfb4120d1a33
Reviewed-on: https://go-review.googlesource.com/c/go/+/671437
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: skip testprogcgo tests in race mode on freebsd
Michael Pratt [Mon, 19 May 2025 21:28:45 +0000 (17:28 -0400)]
runtime: skip testprogcgo tests in race mode on freebsd

These were just enabled by https://go.dev/cl/643897, but freebsd
unfortunately doesn't seem to support cgo + race mode by default.

For #73788.

Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64-race
Change-Id: I6a6a636c06176ca746548d0588283b1429d7c6d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/674160
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>

2 months agounique: add alloc test for Make
Jake Bailey [Thu, 15 May 2025 05:36:57 +0000 (22:36 -0700)]
unique: add alloc test for Make

This will be useful to show how the next CLs improve things.

Change-Id: I49a691295c1fe3c7455a67c7d19e5c03979f714a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673015
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: add scan trace for checkfinalizers>1
Michael Anthony Knyszek [Wed, 2 Apr 2025 01:37:30 +0000 (01:37 +0000)]
runtime: add scan trace for checkfinalizers>1

This change dumps a scan trace (each pointer marked and where it came
from) for the partial GC cycle performed by checkfinalizers mode when
checkfinalizers>1. This is useful for quickly understanding why certain
values are reachable without having to pull out tools like viewcore.

For #72949.

Change-Id: Ic583f80e9558cdfe1c667d27a1d975008dd39a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/662038
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agointernal/filepathlite: fix comment
MaineK00n [Wed, 14 May 2025 21:44:19 +0000 (21:44 +0000)]
internal/filepathlite: fix comment

fix typo

Change-Id: I46f0b052615d388a852439e63542b43e2ca62b7e
GitHub-Last-Rev: 96ac66c0362c5c544249cf465c528a924112fa76
GitHub-Pull-Request: golang/go#73725
Reviewed-on: https://go-review.googlesource.com/c/go/+/672955
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agoruntime: mark and identify tiny blocks in checkfinalizers mode
Michael Anthony Knyszek [Fri, 9 May 2025 18:53:06 +0000 (18:53 +0000)]
runtime: mark and identify tiny blocks in checkfinalizers mode

This change adds support for identifying cleanups and finalizers
attached to tiny blocks to checkfinalizers mode. It also notes a subtle
pitfall, which is that the cleanup arg, if tiny-allocated, could end up
co-located with the object with the cleanup attached! Oops...

For #72949.

Change-Id: Icbe0112f7dcfc63f35c66cf713216796a70121ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/662037
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
2 months agoruntime: annotate checkfinalizers reports with source and type info
Michael Anthony Knyszek [Tue, 1 Apr 2025 19:38:39 +0000 (19:38 +0000)]
runtime: annotate checkfinalizers reports with source and type info

This change adds a new special kind called CheckFinalizer which is used
to annotate finalizers and cleanups with extra information about where
that cleanup or finalizer came from.

For #72949.

Change-Id: I3c1ace7bd580293961b7f0ea30345a6ce956d340
Reviewed-on: https://go-review.googlesource.com/c/go/+/662135
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile: fold negation into addition/subtraction on arm64
Julian Zhu [Sat, 17 May 2025 06:30:07 +0000 (14:30 +0800)]
cmd/compile: fold negation into addition/subtraction on arm64

Fold negation into addition/subtraction and avoid double negation.

platform: linux/arm64

file      before    after     Δ       %
addr2line 3628108   3628116   +8      +0.000%
asm       6208353   6207857   -496    -0.008%
buildid   3460682   3460418   -264    -0.008%
cgo       5572988   5572492   -496    -0.009%
compile   26042159  26041039  -1120   -0.004%
cover     6304328   6303472   -856    -0.014%
dist      4139330   4139098   -232    -0.006%
doc       9429305   9428065   -1240   -0.013%
fix       3997189   3996733   -456    -0.011%
link      8212128   8210280   -1848   -0.023%
nm        3620056   3619696   -360    -0.010%
objdump   5920289   5919233   -1056   -0.018%
pack      2892250   2891778   -472    -0.016%
pprof     17094569  17092745  -1824   -0.011%
test2json 3335825   3335529   -296    -0.009%
trace     15842080  15841456  -624    -0.004%
vet       9472194   9471106   -1088   -0.011%
go        19081541  19081509  -32     -0.000%
total     154253374 154240622 -12752  -0.008%

platform: darwin/arm64

file    before    after     Δ       %
compile 27152002  27135490  -16512  -0.061%
link    8372914   8356402   -16512  -0.197%
go      19154802  19154778  -24     -0.000%
total   157734180 157701132 -33048  -0.021%

Change-Id: I15a349bfbaf7333ec3e4a62ae4d06f3f371dfb1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/673715
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agonet: avoid using Windows' TransmitFile on non-server machines
Shibi J M [Tue, 20 May 2025 03:59:15 +0000 (03:59 +0000)]
net: avoid using Windows' TransmitFile on non-server machines

Windows API's TransmitFile function is limited to two concurrent
operations on workstation and client versions of Windows. This change
modifies the net.sendFile function to perform no work in such cases
so that TransmitFile is avoided.

Fixes #73746

Change-Id: Iba70d5d2758bf986e80c78254c8e9e10b39bb368
GitHub-Last-Rev: 315ddc0cd8034f52632dc31baf35057a8bad9bcd
GitHub-Pull-Request: golang/go#73758
Reviewed-on: https://go-review.googlesource.com/c/go/+/673855
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
2 months agocmd/go: do not try to load 'all' packages with invalid import paths
Michael Matloob [Fri, 16 May 2025 20:40:55 +0000 (16:40 -0400)]
cmd/go: do not try to load 'all' packages with invalid import paths

Before this change, when we tried to compute the set of packages in
'all', we'd add packages with invalid import paths to the set and try to
load them, which would fail. Instead, do not add them to the list of
packages to load in the second iteration of the loader. We'll still
return errors for invalid imports in the importing packages.
Change-Id: I682229011f555ed1d0c827f79100c1c43bf7f93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673655
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/compile: don't instrument counter globals in internal/fuzz
Mateusz Poliwczak [Fri, 16 May 2025 19:07:46 +0000 (21:07 +0200)]
cmd/compile: don't instrument counter globals in internal/fuzz

Fixes: #72766
Change-Id: I45b521e53c2a11e259dc99e2dfc8e40cac39139a
Reviewed-on: https://go-review.googlesource.com/c/go/+/673575
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
2 months agocmd/compile: add generic simplifications on riscv64
Julian Zhu [Sat, 17 May 2025 13:45:50 +0000 (21:45 +0800)]
cmd/compile: add generic simplifications on riscv64

file      before    after     Δ       %
addr2line 3636263   3636215   -48     -0.001%
asm       6318110   6317966   -144    -0.002%
buildid   3463352   3463224   -128    -0.004%
cgo       5672502   5672214   -288    -0.005%
compile   26904997  26905719  +722    +0.003%
cover     6405603   6405467   -136    -0.002%
dist      4092630   4092494   -136    -0.003%
doc       9728281   9723977   -4304   -0.044%
fix       4014891   4014835   -56     -0.001%
link      8327674   8327426   -248    -0.003%
nm        3628718   3628494   -224    -0.006%
objdump   5951778   5951626   -152    -0.003%
pack      2896080   2896040   -40     -0.001%
pprof     17596796  17591908  -4888   -0.028%
test2json 3346622   3346566   -56     -0.002%
trace     16179738  16175706  -4032   -0.025%
vet       9603472   9603264   -208    -0.002%
total     156070021 156055655 -14366  -0.009%

Change-Id: Ie4a79a3c410eb79155ce2418ae64fa670d1ccd53
Reviewed-on: https://go-review.googlesource.com/c/go/+/673477
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2 months agoruntime: add new GODEBUG checkfinalizer
Michael Anthony Knyszek [Mon, 9 Dec 2024 19:07:40 +0000 (19:07 +0000)]
runtime: add new GODEBUG checkfinalizer

This new debug mode detects cleanup/finalizer leaks using checkmark
mode. It runs a partial GC using only specials as roots. If the GC can
find a path from one of these roots back to the object the special is
attached to, then the object might never be reclaimed. (The cycle could
be broken in the future, but it's almost certainly a bug.)

This debug mode is very barebones. It contains no type information and
no stack location for where the finalizer or cleanup was created.

For #72949.

Change-Id: Ibffd64c1380b51f281950e4cfe61f677385d42a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/634599
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>

2 months agocmd/internal/testdir: filter out errors outside input file set
Jake Bailey [Wed, 14 May 2025 05:01:43 +0000 (22:01 -0700)]
cmd/internal/testdir: filter out errors outside input file set

When an errorcheck test uses -m and instantiates an imported generic
function, the errors will include -m messages from the imported package
(since the new function has not previously been walked). These errors
cannot be matched since we can't write errors in files outside the test
input.

To fix this (and enable the other CLs in this stack), drop any unmatched
errors that occur in files outside those in the input set.

Change-Id: I2fcf0dd4693125d2e5823ea4437011730d8b1b1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/672515
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>

2 months agocmd/dist: pass GO_GCFLAGS to cpuN runtime tests
khr@golang.org [Tue, 20 May 2025 15:42:24 +0000 (08:42 -0700)]
cmd/dist: pass GO_GCFLAGS to cpuN runtime tests

We want gcflags, which control builder type (e.g. noopt) to be used
for these tests also.

Should fix noopt and maybe other builders.

Change-Id: Iad34beab51714f0c38989ec0fc8778cf79087f72
Reviewed-on: https://go-review.googlesource.com/c/go/+/674455
Reviewed-by: Keith Randall <khr@google.com>
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>
2 months agocmd/compile/internal/escape: additional constant and zero value tests and logging
thepudds [Wed, 12 Feb 2025 23:39:08 +0000 (18:39 -0500)]
cmd/compile/internal/escape: additional constant and zero value tests and logging

This adds additional logging for the work that walk does to reduce
how often an interface conversion results in an allocation.

Also, as part of #71359, we will be updating how escape analysis and
walk handle basic literals, composite literals, and zero values,
so add some tests that uses this new logging.

By the end of our CL stack, we address all of these tests.

Updates #71359

Change-Id: I43fde8343d9aacaec1e05360417908014a86c8bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/649076
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agohash/maphash: hash channels in purego version of maphash.Comparable
Vladislav Yarmak [Sat, 10 May 2025 17:58:48 +0000 (17:58 +0000)]
hash/maphash: hash channels in purego version of maphash.Comparable

This change makes purego implementation of maphash.Comparable consistent
with the one in runtime and fixes hashing of channels.

Fixes #73657

Change-Id: If78a21d996f0c20c0224d4014e4a4177b09c3aa3
GitHub-Last-Rev: 2537216a1e4e62791c7e417441ee770ca149f38a
GitHub-Pull-Request: golang/go#73660
Reviewed-on: https://go-review.googlesource.com/c/go/+/671655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
2 months agonet/http: upon http redirect, copy Request.GetBody in new request
Marc-Antoine Ruel [Fri, 18 Apr 2025 17:48:04 +0000 (13:48 -0400)]
net/http: upon http redirect, copy Request.GetBody in new request

This enable http.RoundTripper implementation to retry POST request (let's
say after a 500) after a 307/308 redirect.

Fixes #73439

Change-Id: I4365ff58b012c7f0d60e0317a08c98b1d48f657e
Reviewed-on: https://go-review.googlesource.com/c/go/+/666735
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
2 months agoruntime: prevent unnecessary zeroing of large objects with pointers
Michael Anthony Knyszek [Fri, 21 Mar 2025 16:26:15 +0000 (16:26 +0000)]
runtime: prevent unnecessary zeroing of large objects with pointers

CL 614257 refactored mallocgc but lost an optimization: if a span for a
large object is already backed by memory fresh from the OS (and thus
zeroed), we don't need to zero it. CL 614257 unconditionally zeroed
spans for large objects that contain pointers.

This change restores the optimization from before CL 614257, which seems
to matter in some real-world programs.

While we're here, let's also fix a hole with the garbage collector being
able to observe uninitialized memory of the large object is observed
by the conservative scanner before being published. The gory details are
in a comment in heapSetTypeLarge. In short, this change makes
span.largeType an atomic variable, such that the GC can only observe
initialized memory if span.largeType != nil.

Fixes #72991.

Change-Id: I2048aeb220ab363d252ffda7d980b8788e9674dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/659956
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: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
2 months agoruntime: only update freeIndexForScan outside of the mark phase
Michael Anthony Knyszek [Tue, 13 May 2025 20:09:57 +0000 (20:09 +0000)]
runtime: only update freeIndexForScan outside of the mark phase

Currently, it's possible for asynchronous preemption to observe a
partially initialized object. The sequence of events goes like this:
- The GC is in the mark phase.
- Thread T1 is allocating object O1.
- Thread T1 zeroes the allocation, runs the publication barrier, and
  updates freeIndexForScan. It has not yet updated the mark bit on O1.
- Thread T2 is conservatively scanning some stack frame.
  That stack frame has a dead pointer with the same address as O1.
- T2 picks up the pointer, checks isFree (which checks
  freeIndexForScan without an import barrier), and sees that O1 is
  allocated. It marks and queues O1.
- T2 then goes to scan O1, and observes uninitialized memory.

Although a publication barrier was executed, T2 did not have an import
barrier. T2 may thus observe T1's writes to zero the object out-of-order
with the write to freeIndexForScan.

Normally this would be impossible if T2 got a pointer to O1 from
somewhere written by T1. The publication barrier guarantees that if the
read side is data-dependent on the write side then we'd necessarily
observe all writes to O1 before T1 published it. However, T2 got the
pointer 'out of thin air' by scanning a stack frame with a dead pointer
on it.

One fix to this problem would be to add the import barrier in the
conservative scanner. We would then also need to put freeIndexForScan
behind the publication barrier, or make the write to freeIndexForScan
exactly that barrier.

However, there's a simpler way. We don't actually care if conservative
scanning observes a stale freeIndexForScan during the mark phase.
Newly-allocated memory is always marked at the point of allocation (the
allocate-black policy part of the GC's design). So it doesn't actually
matter that if the garbage collector scans that memory or not.

This change modifies the allocator to only update freeIndexForScan
outside the mark phase. This means freeIndexForScan is essentially
a snapshot of freeindex at the point the mark phase started. Because
there's no more race between conservative scanning and newly-allocated
objects, the complicated scenario above is no longer a possibility.

One thing we do have to be careful of is other callers of isFree.
Previously freeIndexForScan would always track freeindex, now it no
longer does. This change thus introduces isFreeOrNewlyAllocated which is
used by the conservative scanner, and uses freeIndexForScan. Meanwhile
isFree goes back to using freeindex like it used to. This change also
documents the requirement on isFree that the caller must have obtained
the pointer not 'out of thin air' but after the object was published.
isFree is not currently used anywhere particularly sensitive (heap dump
and checkmark mode, where the world is stopped in both cases) so using
freeindex is both conceptually simple and also safe.

Change-Id: If66b8c536b775971203fb4358c17d711c2944723
Reviewed-on: https://go-review.googlesource.com/c/go/+/672340
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/go: extend the ignore directive for indexed modules
Sam Thanawalla [Mon, 19 May 2025 16:49:57 +0000 (16:49 +0000)]
cmd/go: extend the ignore directive for indexed modules

For modules that have already been indexed, we can skip ignored paths.
We already skip 'testdata' and '_' for this case so we can extend the
ignore directive for this case as well.

Updates: #42965
Change-Id: I076a242ba65c7b905b9dc65dcfb0a0247cbd68d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/674076
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

2 months agocmd/go: add 2 scripts test for git sha256 fetching
David Finkel [Wed, 14 May 2025 00:54:15 +0000 (20:54 -0400)]
cmd/go: add 2 scripts test for git sha256 fetching

Fast follow to golang.org/cl/636475 with a couple script tests that
build/runs a module that depends on a function inside a git repo using
sha256 hashes. (one with go get of a branch-name and the other
configuring go.mod directly)

Change-Id: Ief6c7efaf6d5c066dc54a3e4a63aad109f625abe
Reviewed-on: https://go-review.googlesource.com/c/go/+/672435
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
2 months agocmd/go/internal/modload: remove likely vestigial ability to infer module path from...
thepudds [Wed, 9 Apr 2025 21:43:14 +0000 (17:43 -0400)]
cmd/go/internal/modload: remove likely vestigial ability to infer module path from Godeps.json and vendor.json

CL 518776 deleted the cmd/go/internal/modconv package and dropped the
ability to import dependency requirements from ~nine or so legacy
pre-module dependency configuration files. Part of the rationale from
Russ in 2023 for dropping that support was that "by now no one is
running into those configs anymore during 'go mod init'".

For two of those legacy file formats, Godeps.json and vendor.json, the
ability to import their listed dependencies was dropped in CL 518776,
but what remained for those two formats was the ability to guess the
resulting module name in the absence of a name being supplied to 'go mod
init'.

This could be explained by the fact that this smaller functionality for
guessing a module name was separate, did not rely on the deleted modconv
package, and instead only relied on simple JSON parsing.

The name guessing was helpful as part of the transition when module
support was initially released, but it was never perfect, including the
various third-party dependency managers did not all have the same naming
rules that were enforced by modules.

In short, it is very unlikely anyone is relying on this now, so we
delete it.

This CL was spawned from discussion in two related documentation CLs
(CL 662675 and CL 662695).

Updates #71537

Change-Id: I9e087aa296580239562a0ecee58913c5edc533ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/664315
Reviewed-by: Michael Matloob <matloob@google.com>
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>
Auto-Submit: Sam Thanawalla <samthanawalla@google.com>

2 months agotesting: use a pattern to match the elapsed time in TestTRun
Mateusz Poliwczak [Tue, 20 May 2025 07:46:53 +0000 (09:46 +0200)]
testing: use a pattern to match the elapsed time in TestTRun

Fixes #73723
Fixes #73737
Fixes #73739

Change-Id: I1ebd3614614285c3e660d48241389bb0f896be23
Reviewed-on: https://go-review.googlesource.com/c/go/+/674355
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
2 months agocmd/compile: align stack-allocated backing stores higher than required
Keith Randall [Thu, 17 Apr 2025 05:48:06 +0000 (22:48 -0700)]
cmd/compile: align stack-allocated backing stores higher than required

Because that's what mallocgc did and some user code came to rely on it.

Fixes #73199

Change-Id: I45ca00d2ea448e6729ef9ac4cec3c1eb0ceccc89
Reviewed-on: https://go-review.googlesource.com/c/go/+/666116
Reviewed-by: t hepudds <thepudds1460@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2 months agocmd/compile: don't preload registers if destination already scheduled
khr@golang.org [Wed, 14 May 2025 00:53:45 +0000 (17:53 -0700)]
cmd/compile: don't preload registers if destination already scheduled

In regalloc, we allocate some values to registers before loop entry,
so that they don't need to be loaded (from spill locations) during
the loop.

But it is pointless if we've already regalloc'd the loop body.
Whatever restores we needed for the body are already generated.

It's not clear if this code is ever useful. No tests fail if I just
remove it. But at least this change is worthwhile. It doesn't help,
and it actively inserts more restores than we really need (mostly
because the desired register list is approximate - I have seen cases
where the loads implicated here end up being dead because the restores
hit the wrong registers and the edge shuffle pass knows it needs
the restores in different registers).

While we are here, might as well have layoutRegallocOrder return
the standard layout order instead of recomputing it.

Change-Id: Ia624d5121de59b6123492603695de50b272b277f
Reviewed-on: https://go-review.googlesource.com/c/go/+/672735
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>