3 ms·

>However, if the object escapes to the heap Can this be detected statically?

mwuertinger 8y ago
Yes this is decided at compile time. If you build your program with `-gcflags '-m'` the compiler will print out detailed escape analysis information. Here's more information: http://www.agardner.me/golang/garbage/collection/gc/escape/analysis/2015/10/18/go-escape-analysis.html http://www.agardner.me/golang/garbage/collection/gc/escape/a...
- presscast 8y ago
  Nice! So this could presumably be built into a linter (or similar) and be flagged in the editor ... interesting...
  - masklinn 8y ago
    IIRC you can't really flag an object as normally escaping so it would be very noisy.
    - IshKebab 8y ago
      You could do it with a subtle colouring scheme.
  - dis-sys 8y ago
    very nice idea.
  - jimmy1 8y ago
    As a heuristic it would be OK, however, there are some situations where the escape analysis algorithms don't detect certain scenarios so a linter may lead you to believe things are not escaping but in reality they really are, it's also implementation specific, so something that may have escaped in go 1.10 may no longer escape in 1.11 for example. It's easy enough to profile and benchmark in go, so I would always treat that as the source of truth.
  - pcwalton 8y ago
    It would be better to spend this effort to add generational GC with a bump allocator to Go. That way memory allocation becomes faster for everyone, not just the tiny subset of people who use fancy tools.
    - weberc2 8y ago
      I think you've made yourself clear. You've jumped into half a dozen threads in this post with some variation of the same comment as you do with every Go GC post. Your comment is interesting, but repeating it over and over is tiresome. Have you reached out to the Go GC team? What is their response?
deleted 8y ago
[deleted]
masklinn 8y ago
There are heuristics — and they improve from version to version — but they're necessarily conservative: heap allocating something which doesn't escape is a performance hit, stack-allocating something which does breaks software.
javier2 8y ago
The compiler can in certain conditions prove that a value does not escape to the heap. Ergo, this value is safe to allocate on stack.

Yes this is decided at compile time. If you build your program with `-gcflags '-m'` the compiler will print out detailed escape analysis information. Here's more information: http://www.agardner.me/golang/garbage/collection/gc/escape/analysis/2015/10/18/go-escape-analysis.html http://www.agardner.me/golang/garbage/collection/gc/escape/a...

presscast 8y ago
Nice! So this could presumably be built into a linter (or similar) and be flagged in the editor ... interesting...
- masklinn 8y ago
  IIRC you can't really flag an object as normally escaping so it would be very noisy.
  - IshKebab 8y ago
    You could do it with a subtle colouring scheme.
- dis-sys 8y ago
  very nice idea.
- jimmy1 8y ago
  As a heuristic it would be OK, however, there are some situations where the escape analysis algorithms don't detect certain scenarios so a linter may lead you to believe things are not escaping but in reality they really are, it's also implementation specific, so something that may have escaped in go 1.10 may no longer escape in 1.11 for example. It's easy enough to profile and benchmark in go, so I would always treat that as the source of truth.
- pcwalton 8y ago
  It would be better to spend this effort to add generational GC with a bump allocator to Go. That way memory allocation becomes faster for everyone, not just the tiny subset of people who use fancy tools.
  - weberc2 8y ago
    I think you've made yourself clear. You've jumped into half a dozen threads in this post with some variation of the same comment as you do with every Go GC post. Your comment is interesting, but repeating it over and over is tiresome. Have you reached out to the Go GC team? What is their response?

deleted 8y ago

[deleted]

masklinn 8y ago

There are heuristics — and they improve from version to version — but they're necessarily conservative: heap allocating something which doesn't escape is a performance hit, stack-allocating something which does breaks software.

javier2 8y ago

The compiler can in certain conditions prove that a value does not escape to the heap. Ergo, this value is safe to allocate on stack.