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: struct field alive too long #24263
Comments
|
In program2, when t passed to fmt.Println(), it is treated as interface{}, as an interface, it should keep its real value and its type descriptor. |
@cherrymui the address of a copy of |
@go101 you are right.
And the memory usage is low as program1. |
@go101
Maybe we can change convT2E64 to take a uint64 value instead of pointer? I'm not sure about its impact and concerns, though. |
That’s a good idea. Should be safe, because it is guaranteed to be scalar—pointer-shaped values don’t go through a convT2x call. Same probably holds for other specialized functions in runtime/iface.go, although for the multi-word ones (slice, string), it might be better to stick with an address to keep the call site small. This would make a decent starter change for someone who wants to work on the runtime+compiler. Not trivial, but straightforward enough. Or you could just do it. :) |
That would solve this particular instance, but it doesn't solve the general problem of:
But maybe that's ok and I'm just being too critical of a live variable analysis that is necessarily going to be conservative in some situations.
The thing that I think originally tripped me up is that |
Filed #24286 for Cherry's suggestion. |
Program 1:
Program 2:
In program 1, the allocation at
make
is garbage collected, so program 1 prints just ~100KB of usage.In program 2, the allocation at
new
is not garbage collected, so it prints ~8MB.The allocation in program 2 should be GCd, it is no longer referenced.
For some reason the compiler is keeping all of t alive even though only one field of it is alive after GC.
Strangely, if I replace
fmt.Println
withprintln
, then the allocation gets GCd.I'm not entirely sure what is going on yet, but it looks like
t
is being treated as addressable. But it is getting decomposed correctly. Strange.First reported here: https://groups.google.com/forum/#!topic/golang-nuts/4qmn5gw7OBQ
The text was updated successfully, but these errors were encountered: