3 ms·
I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.
by pkulak 5y ago
I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.
- mftb 5y agoIt's pretty straightforward, knowing when to use the stack vs heap can improve your performance. Having both paradigms available in the language means you can start out relying on the GC for everything. Later when you're ready, you can look to make more intelligent use of the stack.
- bashery 5y ago+1
- hnov 5y agoI think it's at least partially about value vs (mutable) reference semantics in Golang's case and the hope is that the compiler will know to whether heap or stack allocate based on escape analysis.
- Laremere 5y agoGo uses escape analysis to ensure memory safety of pointers. Taking a reference of a local variable means it might end up on the heap, and calling new might allocate on the stack. It all depends on if Go can determine that the lifetime of the pointers is less than the stack frame. It's good if you don't want to care about those details, it's bad if you really care about those details for performance reasons.
- foldr 5y ago>and makes you memorize when to use stack vs heap You don't have to think about stack vs. heap allocation in Go unless you're writing performance sensitive code. You could pretend that Go heap allocates everything and still read and write Go code without any problems.
- lawl 5y agoHits the sweet spot for me between the one extreme of having to malloc/free everything myself and the other extreme where everything is immutable, garbage collected and you dont know what causes allocation. The former is a nightmare for security and productivity, the latter is a nightmare for performance.
- int_19h 5y agoGo can implicitly heap-allocate even a local variable if you e.g. capture it in a closure. This is actually more implicit than you get in Java or C#.
- morelisp 5y agoJava can decide to heap-allocate or not heap-allocate at runtime based on what optimizations the JIT has performed so far, and so it can change over the course of a program's run. I don't think you can get more implicit than that.
- int_19h 5y agoWhy would Java ever heap-allocate a local, regardless of optimizations? It can decide to heap-allocate or stack-allocate objects (when you new them) based on escape analysis, which is a JIT optimization. But that's very different from heap-allocating variables.
- morelisp 5y agoThen I'm not even sure what you're talking about when you say "heap-allocate even a local variable" if you don't actually mean the value of that variable. If you draw that distinction, "variables" are never allocated; spaces for values are. Regardless, whether something is a local or not in Java still varies depending on the JIT's decisions. (Or rather, the JIT does not see local/non-local variables, only lifetimes, and whether the lifetime may extend past the JIT's current view.)
- 5y ago
- deleted 5y ago[deleted]
- pjmlp 5y agoPerformance, Java made the mistake to not have good ways to deal with GC free allocations and now who knows when Valhala will ever happen. Thankfully plenty of other GC based languages hadn't made the same mistake.