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

cmd/compile: variables that only survive within the function escape to the heap #63964

Closed
qiulaidongfeng opened this issue Nov 6, 2023 · 5 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@qiulaidongfeng
Copy link
Member

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

$ go version
tip

Does this issue reproduce with the latest release?

yes.

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

Can be reproduced in https://go.dev/play

What did you do?

This is the minimum copy code I have written.

https://go.dev/play/p/CMcVGAsizeN?v=gotip

What did you expect to see?

I want to see variables that only survive in function memory being allocated to the stack.

What did you see instead?

I see variables that only survive in function memory being allocated to the heap.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 6, 2023
@mateusz834
Copy link
Member

mateusz834 commented Nov 6, 2023

This might be related to #16241. #57910. (once := OnceValue[[]string]{} probably escapes, because it uses a sync.Mutex).

@mauri870
Copy link
Member

mauri870 commented Nov 6, 2023

By removing the mutex it still escapes once to the heap. I believe it is the internal call to (sync.Once).Do that makes it escape, because of the atomic ops

Shorter example: https://go.dev/play/p/RFXBKkEFrfO

go build -gcflags=-m=2 main.go
# command-line-arguments
./main.go:12:6: cannot inline escapes: function too complex: cost 87 exceeds budget 80
./main.go:13:12: can inline escapes.func1 with cost 4 as: func() { p.b = true }
./main.go:13:11: inlining call to sync.(*Once).Do
./main.go:13:11: inlining call to atomic.(*Uint32).Load
./main.go:18:6: can inline doesntescape with cost 4 as: func(*V) { p.b = true }
./main.go:22:6: can inline main with cost 73 as: func() { vv = <nil>; escapes(&vv); doesntescape(&vv) }
./main.go:25:14: inlining call to doesntescape
./main.go:12:14: escapes capturing by value: p (addr=false assign=false width=8)
./main.go:12:14: parameter p leaks to {heap} with derefs=0:
./main.go:12:14:   flow: sync.o = p:
./main.go:12:14:     from p.once (dot of pointer) at ./main.go:13:3
./main.go:12:14:     from p.once (address-of) at ./main.go:13:8
./main.go:12:14:     from sync.o, sync.f := p.once, func literal (assign-pair) at ./main.go:13:11
./main.go:12:14:   flow: {heap} = sync.o:
./main.go:12:14:     from (*sync.Once).doSlow(sync.o, sync.f) (call parameter) at ./main.go:13:11
./main.go:12:14: leaking param: p
./main.go:13:12: func literal does not escape
./main.go:18:19: p does not escape
./main.go:23:6: vv escapes to heap:
./main.go:23:6:   flow: {heap} = &vv:
./main.go:23:6:     from &vv (address-of) at ./main.go:24:10
./main.go:23:6:     from escapes(&vv) (call parameter) at ./main.go:24:9
./main.go:23:6: moved to heap: vv

@heschi
Copy link
Contributor

heschi commented Nov 6, 2023

cc @golang/compiler

@heschi heschi added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 6, 2023
@heschi heschi added this to the Backlog milestone Nov 6, 2023
@mauri870
Copy link
Member

mauri870 commented Nov 6, 2023

This seems to be the same as #57910, I just tested the fix proposed at CL462299 and it seems to prevents it from escaping.

@mdempsky
Copy link
Contributor

mdempsky commented Nov 6, 2023

This seems to be the same as #57910

Thanks for finding that! I agree, it looks like the same issue. Closing this one as a duplicate.

@mdempsky mdempsky closed this as completed Nov 6, 2023
@mdempsky mdempsky reopened this Nov 6, 2023
@mdempsky mdempsky closed this as not planned Won't fix, can't repro, duplicate, stale Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants