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
container/heap: confusing claim of memory leak when shrinking slices #65403
Comments
Change https://go.dev/cl/559775 mentions this issue: |
This is about a comment internal to the standard library, not any actual user-facing documentation. You do not need to file an issue for this sort of thing in the future. You can just send a change and it will get reviewed. If you're unsure whether it's worth the effort, start a thread on https://groups.google.com/g/golang-dev first. Thanks. Closing this issue. |
Alright thanks, I'll remember it. However, this is indeed user-facing documentation. It is part of an example, that is visible here: https://pkg.go.dev/container/heap@go1.21.6#example-package-PriorityQueue |
Oh! Thank you. My apologies for not looking closely enough. |
The term "memory leak" was misused here, as the memory is still referenced by the slice. Fixes golang#65403 Change-Id: Id102419d4c798fb2a4ec8be86be9ec9b5cdd98e6 GitHub-Last-Rev: 3febcd0 GitHub-Pull-Request: golang#65404 Reviewed-on: https://go-review.googlesource.com/c/go/+/559775 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Go version
go version go1.21.1 openbsd/amd64
Output of
go env
in your module/workspace:What did you do?
I read the "PriorityQueue" example of the
container/heap
documentation.What did you see happen?
I came across this line, claiming to prevent a memory leak. It confused, me since I've never heard of a memory leak caused by Go slices.
Upon some pondering, I figured that the author of this line is talking about the memory, that is retained when shrinking a slice. However, I think the term "memory leak" is not right for this, since the memory will be freed once the slice becomes unused or it will be reused when the slice grows again. At most, I would call this a "space leak".
What did you expect to see?
I would prefer this line to be absent. It seems like a premature optimization to me and doesn't help explaining the
container/heap
package.The text was updated successfully, but these errors were encountered: