Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

gccgo: memory profiling is always enabled by default #59388

Open
ericlagergren opened this issue Apr 2, 2023 · 2 comments
Open

gccgo: memory profiling is always enabled by default #59388

ericlagergren opened this issue Apr 2, 2023 · 2 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Gccgo

Comments

@ericlagergren
Copy link
Contributor

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
@seankhliao seankhliao changed the title gofrontend: memory profiling is always enabled by default gccgo: gofrontend: memory profiling is always enabled by default Apr 3, 2023
@gopherbot gopherbot added this to the Gccgo milestone Apr 3, 2023
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 3, 2023
@seankhliao seankhliao changed the title gccgo: gofrontend: memory profiling is always enabled by default cmd/link,gccgo: memory profiling is always enabled by default with external linker Apr 3, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 3, 2023
@ianlancetaylor
Copy link
Contributor

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

@cherrymui cherrymui changed the title cmd/link,gccgo: memory profiling is always enabled by default with external linker gccgo: memory profiling is always enabled by default Apr 6, 2023
@cherrymui
Copy link
Member

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.

@cherrymui cherrymui removed their assignment Apr 6, 2023
@cherrymui cherrymui removed the compiler/runtime Issues related to the Go compiler and/or runtime. label Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Gccgo
Development

No branches or pull requests
5 participants
@ianlancetaylor @ericlagergren @gopherbot @seankhliao @cherrymui