runtime: greenteagc makes our program slower than old GC on darwin/arm64

[atetubou]

Go version

go version go1.26.0 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/tikuta/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/tikuta/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/6j/px1zc0lj76j9lwrtfbtlr01h00bk9x/T/go-build3797828191=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/tikuta/ghq/chromium.googlesource.com/build/siso/go.mod'
GOMODCACHE='/Users/tikuta/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/tikuta/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/tikuta/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.26.0'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

We are developing distributed build system called siso for chromium build in https://source.chromium.org/chromium/build/+/main:siso/

And when we update from go1.25 to go1.26 for siso, we noticed that chromium build performance become slower when using siso with greenteagc.

• go1.26 w/ greenteagc: 7m:31s
• go1.26 w/o greenteagc: 6m:54s

Unfortunately, we don't have minimal reproducible case. So I attached cpu/memory profile w/ and w/o greenteagc of our build hoping that helps to investigate how greenteagc slows down the build.

siso_greenteagc_profs.tgz

What did you see happen?

Enabling greenteagc is faster than disabling greenteagc.

What did you expect to see?

Enabling greenteagc is slower than disabling greenteagc.

[prattmic]

cc @golang/runtime @mknyszek

[mknyszek]

Thanks for the report! Since we can't reproduce this ourselves (even a slightly complicated reproducer would be fine, haha), can you provide the following additional diagnostics? 1. Output of running with `GODEBUG=gctrace=2,gcpacertrace=1` set, with and without Green Tea. 2. An execution trace of your program executing, with and without Green Tea (it doesn't matter if the trace is huge, I can break it up to analyze it). I'll take a look at the CPU profiles shortly.

…

On Thu, Feb 26, 2026 at 7:51 AM Michael Pratt ***@***.***> wrote: *prattmic* left a comment (golang/go#77824) <#77824 (comment)> cc @golang/runtime <https://github.com/orgs/golang/teams/runtime> @mknyszek <https://github.com/mknyszek> — Reply to this email directly, view it on GitHub <#77824 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQ3HBP4GNFMDFFBAYCBPL4N4I6HAVCNFSM6AAAAACWAWJKICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNRXGQ4DQMJTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mknyszek]

We've been looking at the profiles and there's clearly an increase in CPU time for the GC, but there are some other oddities like memory allocation just seems more expensive? Plus memory allocation is specifically generating contention in the sweeper. It's really not clear to me why Green Tea would change that. It could be some second order effect from false sharing, or perhaps something else. More diagnostics are needed to figure out what's going on. Does the slowdown only reproduce on darwin/arm64? Also, to reiterate from my last message, I don't mind a more complicated reproducer. If I can run it myself I can collect many more diagnostics and dig much deeper. On Thu, Feb 26, 2026 at 9:51 AM Michael Knyszek ***@***.***> wrote:

…

*mknyszek* left a comment (golang/go#77824) <#77824 (comment)> Thanks for the report! Since we can't reproduce this ourselves (even a slightly complicated reproducer would be fine, haha), can you provide the following additional diagnostics? 1. Output of running with `GODEBUG=gctrace=2,gcpacertrace=1` set, with and without Green Tea. 2. An execution trace of your program executing, with and without Green Tea (it doesn't matter if the trace is huge, I can break it up to analyze it). I'll take a look at the CPU profiles shortly. On Thu, Feb 26, 2026 at 7:51 AM Michael Pratt ***@***.***> wrote: > *prattmic* left a comment (golang/go#77824) > <#77824 (comment)> > > cc @golang/runtime <https://github.com/orgs/golang/teams/runtime> > @mknyszek <https://github.com/mknyszek> > > — > Reply to this email directly, view it on GitHub > <#77824 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAJQ3HBP4GNFMDFFBAYCBPL4N4I6HAVCNFSM6AAAAACWAWJKICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNRXGQ4DQMJTGQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#77824 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQ3HFZ4O3G3AZVO5TKYCD4N4XDLAVCNFSM6AAAAACWAWJKICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNRYGIYTINJZGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[prattmic]

I'm also curious to know what GOMAXPROCS is.

[atetubou]

Thank you for taking a look this issue.

I commented how to reproduce this in http://b/485402463#comment13

1. Output of running with GODEBUG=gctrace=2,gcpacertrace=1 set, with and without Green Tea.

I attached output with this flag, but got
pacer: sweep done at heap size 10076MB; allocated 4268MB during sweep; swept 1420630 pages at fatal error: bad sweepgen in refill during nogreenteagc execution.

gc_logs.tgz

2. An execution trace of your program executing, with and without Green Tea

I uploaded the file to internal issue http://b/485402463#comment14 to avoid file size limit in github issue.

Does the slowdown only reproduce on darwin/arm64?

We don't see slow down on linux/amd64, haven't confirm that for Windows.

I'm also curious to know what GOMAXPROCS is.

I run this performance comparison on macbook pro with Apple M4 MAX, and GOMAXPROCS is 16.

[atetubou]

I attached output with this flag, but got
pacer: sweep done at heap size 10076MB; allocated 4268MB during sweep; swept 1420630 pages at fatal error: bad sweepgen in refill during nogreenteagc execution.

Uploaded trace from success execution in http://b/485402463#comment15.

[prattmic]

I attached output with this flag, but got
pacer: sweep done at heap size 10076MB; allocated 4268MB during sweep; swept 1420630 pages at fatal error: bad sweepgen in refill during nogreenteagc execution.

Looks like this is a 1.26 regression in the runtime print. I've filed #77854 and sent a fix.