gccgo: memory profiling is always enabled by default

ericlagergren commented 1 year ago

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

1.18 (ish). I'm using fork of gccgo from devel/gccgo built for vxworks/ppc, but the bug isn't specific to the fork.

Does this issue reproduce with the latest release?

n/a

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

vxworks/ppc and also linux/amd64

What did you do?

Any program that does not reference runtime.MemProfileRate.

What did you expect to see?

The runtime not call profilealloc.

What did you see instead?

The runtime calls profilealloc.

I noticed this while working on a fork of gccgo build for vxworks/ppc. This bug really isn't specific to gccgo—I believe it will occur any time the external linker is used since CL 299671 only applies to cmd/link. Of course, since we're using a fork we could just disable this and we have. But it means that anybody using gccgo (or an external linker) gets hit with a certain performance penalty unless they remember to set runtime.MemProfileRate to zero. It's a relatively minor 'bug', but little things add up quickly on constrained platforms.

/cc: @elagergren-spideroak

ianlancetaylor commented 1 year ago

This is unfortunately rather difficult to fix for gccgo, where we don't control the linker.

cherrymui commented 1 year ago

For the gc toolchain, the optimization will apply even in "external linking mode" (i.e. using the Go linker cmd/link to link Go code to a system object, then using the C linker to generate the executable (potentially linking with C code)).

So this issue is only for gccgo (and gollvm). As gccgo doesn't have its own linker and just uses the C linker, there is not really an "external linker".

As @ianlancetaylor mentioned, this is difficult for gccgo.

A workaround is to set the environment variable GODEBUG=memprofilerate=0.

golang / go