cmd/compile: the Go compiler uses a hack to pretend it has a large startup heap

[dr2chase]

This is a placeholder bug to collect comment, input, experience concerning the compiler's hack. Anyone who sees that code and says "wow, I want this, I will try it myself", we'd like to hear about your experience, either positive or negative, because that is useful for determining if this just stays a hack or if it eventually gets turned into a GC knob. It's important to remember that the compiler is a little bit special; in general its heap use grows and grows (the last phases are some of the most memory-hungry) and it has been carefully tuned and tweaked to reuse allocated objects and avoid generating garbage. Its heap use is very input-dependent, and it also runs on a wide variety of hardware (ODroids and Raspberry Pi, busy laptops shared with greedy browsers, sole-tenant build containers, and 100+ processor and GB servers). Your use case is probably not like the Go compiler, it looks weird in all the GC benchmarks that we do.

What version of Go are you using (go version)?

This is true starting in Go 1.20.

What operating system and processor architecture are you using (go env)?

This is true all places where people run the Go compiler.

What did you do?

In CL 436235, in cmd/compile/internal/base/base.go, the function AdjustStartingHeap does exactly that, using runtime metrics and finalizers to monitor the heap's live size. After-ish each GC, it estimates a new value of GOGC that will generate the requested heap "goal" (the maximum heap size, attained just as a GC cycle completes), and if that is larger than 125, it sets that GOGC and continues monitoring and adjusting. Otherwise, it sets GOGC to 100 and stops the process. This seems to work really well for the compiler, but this is yucky, and relies on finalizers running promptly, which they usually do. This tweak currently has an interaction with manually requested GC, so, be aware of that.

[rabbbit]

Perhaps only tangentially related, but we've hacked around temporarily boost it for rapid starting heap growth for a cli (linter) in by just empirically trying different GOGC values and seeing what (1) works fine (2) doesn't OOM. We've gotten similar results (~10-15% wall time reduction, in order of 0.5s per run). GOGC=off wasn't improving performance, the binary was allocating a lot.

I don't think we'd want a knob to control the heap "goal" per cli/binary in bytes, but something that would automatically help with "starting heap growth" would seem helpful for CLIs/one-shot binaries.