4 ms·
Go doesn’t have traditional stacks; it has growable stacks and they work out very well in practice. But yeah they aren’t segmented to my knowledge.
by throwaway894345 3y ago
Go doesn’t have traditional stacks; it has growable stacks and they work out very well in practice. But yeah they aren’t segmented to my knowledge.
- addaon 3y agoGo has auto-copied stacks [1]. This replaces a deterministic, statically-analyzable problem ("how much stack space does this need, worst case?") with unboundedly bad performance. Yay? [1] https://blog.cloudflare.com/how-stacks-are-handled-in-go/ https://blog.cloudflare.com/how-stacks-are-handled-in-go/
- znkr 3y agoOnly, it’s not statically analyzable. Rice’s theorem still holds afaik
- addaon 3y agoIt's not statically analyzable for arbitrary programs. Don't write arbitrary programs -- design for analysis, just like you design for test.
- znkr 3y agoWhile that’s possible, it would put severe limitations on what you can do. For example, it would be very difficult to parse nested input data and I don’t see how dynamic function Dispatch would be possible at all. I am not convinced that the benefits would outweigh the costs.
- addaon 3y agoThis is standard practice for embedded and high-reliability systems.
- throwaway894345 3y ago1. This isn’t standard practice for high reliability systems. Lots of highly reliable systems don’t prohibit dynamic dispatch, dynamic memory, etc. 2. Most programs (especially Go programs) aren’t embedded, so this isn’t much of a criticism. 3. If you can statically analyze a C program and make sure it doesn’t overflow the stack, why can’t you statically analyze a Go program and make sure it doesn’t grow the stack beyond a certain size? I’m not arguing that Go is a good fit for embedded, but I don’t see why throwable stacks are a major problem.
- zokier 3y agoI don't know, but I have feeling that copying stacks and rewriting pointers gets expensive if stacks grow to heap sized (~gigabytes)
- throwaway894345 3y agoHow many Go programs are bottlenecked by growable stacks? What share of real world programs need precisely deterministic memory management?(and if they do, why not just “design for analysis” like you would with a fixed size stack language).