Go's escape analysis and why my function return worked

Post by simiones » Thu, Dec 11, 2025, 4:00 PM UTC

9rx wrote: post #32

simiones wrote: post #30

Earlier quoted context omitted.

The point the GP was making was that the following Go snippet: func foo() { x := []int { 1 } //SNIP } Could translate to C either as: void foo() { int* x = malloc(1 * sizeof(int)); x[0] = 1; //... } Or as void foo() { int data[1] = {1}; int *x = data; //... } Depending on the content of //SNIP. However, some people think that the semantics can also match the semantics of the second version in C - when in fact the sem…

The semantics are clearly defined as being the same as the C code I posted earlier. Why would one try to complicate the situation by thinking that it would somehow magically change sometimes?

Post by malkia » Thu, Dec 11, 2025, 4:35 PM UTC

carb wrote: post #37

onionisafruit wrote: post #20

Earlier quoted context omitted.

Go has been my primary language for a few years now, and I’ve had to do extra work to make sure I’m avoiding the heap maybe five times. Stack and heap aren’t on my mind most of the time when designing and writing Go, even though I have a pretty good understanding of how it works. The same applies to the garbage collector. It just doesn’t matter most of the time. That said, when it matters it matters a lot. In those t…

Why have you had to avoid the heap? Performance concerns?

Post by Yokohiii » Thu, Dec 11, 2025, 4:50 PM UTC

foldr wrote: post #21

Yokohiii wrote: post #13

Earlier quoted context omitted.

I am currently learning go and your comment made me sort some things out, but probably in a counterintuitive way. Assuming to everything allocates on the heap, will solve this specific confusion. My understanding is that C will let you crash quite fast if the stack becomes too large, go will dynamically grow the stack as needed. So it's possible to think you're working on the heap, but you are actually threshing the…

Go won’t put large allocations on the stack even if escape analysis would permit it, so generally speaking this should only be a concern if you have very deep recursion (in which case you might have to worry about stack overflows anyway).

Post by foldr » Thu, Dec 11, 2025, 5:21 PM UTC

9rx wrote: post #26

foldr wrote: post #3

This seems to be a persistent source of confusion. Escape analysis is just an optimization. You don't need to think about it to understand why your Go code behaves the way it does. Just imagine that everything is allocated on the heap and you won't have any surprises.

> This seems to be a persistent source of confusion. Why? It is the same as in C. #include #include struct slice { int *data; size_t len; size_t cap; }; struct slice readLogsFromPartition() { int *data = malloc(2); data[0] = 1; data[1] = 2; return (struct slice){ data, 2, 2 }; } int main() { struct slice s = readLogsFromPartition(); for (int i = 0; i

    int *foo(void) {
        int x = 99;
        return &x; // bad idea
    }

    func foo() *int {
        x := 99
        return &x // fine
    }

Post by throwaway894345 » Thu, Dec 11, 2025, 5:43 PM UTC

Yokohiii wrote: post #14

throwaway894345 wrote: post #12

Earlier quoted context omitted.

I like Go a lot, but I often wish we could be more explicit about where allocations are. It’s often important for writing performant code, but instead of having semantics we have to check against the stack analyzer which has poor ergonomics and may break at any time. But yeah, to your point, returning a slice in a GC language is not some exotic thing.

Can you elaborate on the stack analyzer? All I could figure out was to see runtime.morestack calls that affected the runtime, but as far I remember the caller timings did exclude the cost. Having a clearer view of stack grow rates would be really great.