Skip to content

runtime: slowdown with green tea garbage collector #74923

@bep

Description

@bep

Go version

go version go1.25rc3 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/bep/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/bep/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/_g/j3j21hts4fn7__h04w2x8gb40000gn/T/go-build2628208990=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/bep/dev/go/gohugoio/hugo/go.mod'
GOMODCACHE='/Users/bep/dev/gomod_cache'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/bep/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org'
GOROOT='/Users/bep/sdk/go1.25rc3'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/Users/bep/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/bep/sdk/go1.25rc3/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25rc3'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Build Hugo in two versions:

  1. With export GOEXPERIMENT=greenteagc
  2. With export GOEXPERIMENT=nogreenteagc

Then build this project https://github.com/bep/many-big-json-in-assets with both binaries:

HUGO_MEMORYLIMIT=8 hugo_greenteagc --logLevel info
HUGO_MEMORYLIMIT=8 hugo_nogreenteagc --logLevel info

What did you see happen?

I have repeated the above multiple times, and I get consistently build times around 40 seconds with geentea enabled, and around 20 seconds with it disabled.

Note that this has been reported before using rc1, and closed as fixed in #74375 -- but that points at a particular issue with nil checks on Linux.

I have tested the above on my MacBook Pro M1 with 32 GB memory.

What did you expect to see?

I expected the new garbage collector to be more effective, and at least not twice as ineffective, for the above case.

Metadata

Metadata

Assignees

Labels

BugReportIssues describing a possible bug in the Go implementation.NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions