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/gc: name closure for outer function #8291

Closed
gopherbot opened this issue Jun 26, 2014 · 11 comments
Closed

cmd/gc: name closure for outer function #8291

gopherbot opened this issue Jun 26, 2014 · 11 comments
Milestone

Comments

@gopherbot
Copy link
Contributor

by Matthew.Horsnell:

What does 'go version' print?
go version go1.3 linux/amd64

What steps reproduce the problem?

Profile any code with closures in it.

What happened?

The profile information contains non-specific function names for closures i.e.
<package>.func.<d>.

What should have happened instead?

Ideally it would be nice to at least know where the closure was generated in the package
i.e. <package>.<closure generating func>.func.<d>
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-go1.4.

@gopherbot
Copy link
Contributor Author

Comment 2 by Matthew.Horsnell:

As an additional, obvious, note. The anonymous functions can not be viewed from list in
go tool pprof either.

@gopherbot
Copy link
Contributor Author

Comment 3 by Matthew.Horsnell:

example profile:
Welcome to pprof!  For help, type 'help'.
(pprof) top20 -cum
Total: 785 samples
       0   0.0%   0.0%      785 100.0% main.main
      61   7.8%   7.8%      785 100.0% main.test
       0   0.0%   7.8%      785 100.0% runtime.gosched0
       0   0.0%   7.8%      785 100.0% runtime.main
      16   2.0%   9.8%      509  64.8% github.com/repo/funcA
     391  49.8%  59.6%      493  62.8% github.com/repo/funcB
      25   3.2%  62.8%      159  20.3% math/rand.(*Rand).Uint32
      43   5.5%  68.3%      134  17.1% math/rand.(*Rand).Int63
      91  11.6%  79.9%       91  11.6% math/rand.(*rngSource).Int63
      23   2.9%  82.8%       23   2.9% github.com/repo/funcC
       6   0.8%  83.6%       20   2.5% github.com/repo/package.funcD
       4   0.5%  84.1%       20   2.5% github.com/repo/package.func·016
      11   1.4%  85.5%       15   1.9% github.com/repo/package.func·003
       6   0.8%  86.2%       14   1.8% github.com/repo/package.func·029
       7   0.9%  87.1%       14   1.8% runtime.mapaccess2_faststr
      12   1.5%  88.7%       13   1.7% github.com/repo/package.func·001
      11   1.4%  90.1%       13   1.7% github.com/repo/package.func·005
      12   1.5%  91.6%       13   1.7% github.com/repo/package.func·030
       5   0.6%  92.2%        8   1.0% github.com/repo/package.func·013
       5   0.6%  92.9%        8   1.0% github.com/repo/package.func·017

@gopherbot
Copy link
Contributor Author

Comment 4 by Matthew.Horsnell:

example call to list closure:
(pprof) list package.func·005         
Total: 785 samples
(pprof)

@rsc
Copy link
Contributor

rsc commented Sep 30, 2014

Comment 5:

I think the pprof problem is a Perl Unicode issue. The new pprof written in Go will not
have this problem.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Oct 6, 2014

Comment 6:

I looked into this but it's a little tricky. Leaving for Go 1.5.

Labels changed: added release-go1.5, removed release-go1.4.

@rsc
Copy link
Contributor

rsc commented Oct 16, 2014

Comment 7:

Issue #8943 has been merged into this issue.

@adonovan
Copy link
Member

Comment 8:

I agree this change would help readers of the output of various static and dynamic
analyses.
May I humbly suggest following the naming convention used by the SSA builder?
f$1 for the first function literal within function f.
f$1$2 for the second function literal within f$1, etc.
init$1 for the first function literal among the package's variable initializer
expressions.
init#1 for the first declared init function in the package.
etc.

@rsc
Copy link
Contributor

rsc commented Oct 20, 2014

Comment 9:

There's no need for $ and #. A simple . will work just fine.

@adonovan
Copy link
Member

Comment 10:

> There's no need for $ and #. A simple . will work just fine.
Ok, one of them could be replaced by a dot, and I'll make go/ssa consistent with
whatever you ultimately go with, but you want to distinguish "the first declared init
function" from "the first lambda in a variable initializer", don't you?

@rsc
Copy link
Contributor

rsc commented Oct 23, 2014

Comment 11:

I'll probably just keep calling the top-level closures func.1 func.2, etc.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants