3 ms·

>I'm interested and surprised to see people putting much effort into escape analysis for stack allocation. The research that came out in the 90s and 00s pretty

>I'm interested and surprised to see people putting much effort into escape analysis for stack allocation. The research that came out in the 90s and 00s pretty much said that if you have a good GC you won't see much benefit to using EA for stack allocation. Garbage never generated is garbage never collected. Large enterprise Java apps often still have GC issues despite very advanced GCs to choose from. Also Go's GC is maturing slower than its escape analysis and its object pool (sync.Pool). Go is younger so its GC is weak compared to Java- but it does a good job using the stack and offers a state of the art object pool with thread local caching. >It's very expensive to do EA well (O(n^3) or O(n^6) where n is the depth of the call graph). You can do it cheaper in a JIT that has on-stack-replacement Isn't this apples to oranges since one of these is a compile time expense and the other is a run time expense?

jrobn 12y ago
It seems languages with advanced GCs have same but different problems. Articles about how to reduce garbage generation, minimize heap allocation, etc because of slow and expensive GC collections and pauses. So it seems to me, putting in a little extra effort to reduce heap garbage that the GC has to go clean up is a win. Especially since go doesn't have an advanced JIT.
pron 12y ago
> Garbage never generated is garbage never collected. But garbage that dies young is also garbage that is never collected, and that is the only kind of garbage EA can help with. Objects that die young are very cheap. > Large enterprise Java apps often still have GC issues despite very advanced GCs to choose from Very true, but never in the young generation.
- skybrian 12y ago
  But how do you know it's in the young generation? A long-running thread or goroutine can outlive the young generation and then its heap-allocated objects will need to be moved. Stack allocation is more predictable.
  - pron 12y ago
    > Stack allocation is more predictable. It is. It's just that I recall reading that the difference didn't turn out to be dramatic in practice. The object belonging to the bottom of the stack are promoted (they can't amount to much if they're stack-allocated, because your stacks aren't big anyway), and the reset is young. Whatever is mid-lived probably explains most of the non-dramatic difference (as well as young collections which are very cheap but not entirely free).
coldtea 12y ago
>Go is younger so its GC is weak compared to Java I see this often repeated, and it's false. Go's GC is indeed younger compared to Java, but Go being younger doesn't have anything to do with it. It's not like GC's "mature" and get better with time organically. They mature and get better with the effort put into them, which is different than time. You can have a GC besting an older language's GC in a language that has 1/10 the years the old one has.
- enneff 12y ago
  Yes, it's not true that software magically gets better with age, but we now have a small team of experts working on the Go runtime, so we expect the GC to improve dramatically this year. We didn't have those people before, and one reason for that is that the project was smaller then.
- voidlogic 12y ago
  Sorry, I meant "and" rather than "so" in retrospect. Although youngness of an implementation temporally is obviously often correlated to naivety of implementation.

jrobn 12y ago

It seems languages with advanced GCs have same but different problems. Articles about how to reduce garbage generation, minimize heap allocation, etc because of slow and expensive GC collections and pauses. So it seems to me, putting in a little extra effort to reduce heap garbage that the GC has to go clean up is a win. Especially since go doesn't have an advanced JIT.

pron 12y ago

> Garbage never generated is garbage never collected. But garbage that dies young is also garbage that is never collected, and that is the only kind of garbage EA can help with. Objects that die young are very cheap. > Large enterprise Java apps often still have GC issues despite very advanced GCs to choose from Very true, but never in the young generation.

skybrian 12y ago
But how do you know it's in the young generation? A long-running thread or goroutine can outlive the young generation and then its heap-allocated objects will need to be moved. Stack allocation is more predictable.
- pron 12y ago
  > Stack allocation is more predictable. It is. It's just that I recall reading that the difference didn't turn out to be dramatic in practice. The object belonging to the bottom of the stack are promoted (they can't amount to much if they're stack-allocated, because your stacks aren't big anyway), and the reset is young. Whatever is mid-lived probably explains most of the non-dramatic difference (as well as young collections which are very cheap but not entirely free).

coldtea 12y ago

>Go is younger so its GC is weak compared to Java I see this often repeated, and it's false. Go's GC is indeed younger compared to Java, but Go being younger doesn't have anything to do with it. It's not like GC's "mature" and get better with time organically. They mature and get better with the effort put into them, which is different than time. You can have a GC besting an older language's GC in a language that has 1/10 the years the old one has.

enneff 12y ago
Yes, it's not true that software magically gets better with age, but we now have a small team of experts working on the Go runtime, so we expect the GC to improve dramatically this year. We didn't have those people before, and one reason for that is that the project was smaller then.
voidlogic 12y ago
Sorry, I meant "and" rather than "so" in retrospect. Although youngness of an implementation temporally is obviously often correlated to naivety of implementation.