5 ms·

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 beha

by foldr 11mo ago

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.

bonniesimon 11mo ago
Makes sense. I need to rewire how I think about Go. I should see it how I see JS.
Yokohiii 11mo ago
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 runtime with expensive stack grow calls. Go certainly tries to be smart about it with various strategies, but a rapid stack grow rate will have it's cost.
- foldr 11mo ago
  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).
  - Yokohiii 11mo ago
    Escape analysis accounts for size, so it wouldn't even permit it. The initial stack size seems to be 2kb, a more on a few systems. So far I understand you can allocate a large local i.e. 8kb, that doesn't escape and grow the stack immediately. (Of course that adds up if you have a chain of calls with smaller allocs). So recursion is certainly not the only concern.
    - foldr 11mo ago
      For that to be a problem you either have to have one function that allocates an enormous number of non-escaping objects below the size limit (if the Go compiler doesn't take the total size of all a function's non-escaping allocations into account – I don't know), or a very long series of nested function calls, which in practice is only likely to arise if there are recursive calls.
      - Yokohiii 11mo ago
        I think we mix things up here. But be aware of my newbie knowledge. I am pretty sure the escape analysis doesn't affect the initial stack size. Escape analysis does determine where an allocation lives. So if your allocation is lower then what escape analysis considers heap and bigger then the initial stack size, the stack needs to grow. What I am certain about, is that I have runtime.newstack calls accounting for +20% of my benchmark times (go testing). My code is quite shallow (3-4 calls deep) and anything of size should be on the heap (global/preallocated) and the code has zero allocations. I don't use goroutines either, it might me I still make a mistake or it's the overhead from the testing benchmark. But this obviously doesn't seem to be anything super unusual.
        foldr 11mo ago
        I don't know about your code, but in general, goroutine stacks are designed to start small and grow. There is nothing concerning about this. A call to runtime.newstack triggered by a large stack-allocated value would generally be cheaper than the corresponding heap allocation.
        Yokohiii 11mo ago
        I found my issue, I was creating a 256 item fixed array of a 2*uint8 struct in my code. That was enough to cause newstack calls. It now went down from varying 10% to roughly 1%. Oddly enough it didn't change the ns/op a bit. I guess some mix of workload related irrelevancy and inaccurate reporting or another oversight on my side.
  - masklinn 11mo ago
    > Go won’t put large allocations on the stack even if escape analysis would permit it Depends what you mean by “large”. As of 1.24 Go will put slices several KB into the stack frame: make([]byte, 65536) Goes on the stack if it does not escape (you can see Go request a large stack frame) make([]byte, 65537) goes on the heap (Go calls runtime.makeslice). Interestingly arrays have a different limit: they respect MaxStackVarSize, which was lowered from 10MB to 128 KB in 1.24. If you use indexed slice literals gc does not even check and you can create megabyte-sized slices on the stack.
    - Yokohiii 11mo ago
      There is a option -smallframes that seems to be intended for conservative use cases. Below are the related configs and a test at what point they escape (+1). // -smallframes // ir.MaxStackVarSize = 64 * 1024 // ir.MaxImplicitStackVarSize = 16 * 1024 a := [64 * 1024 +1]byte{} b := make([]byte, 0, 16 * 1024 +1) // default // MaxStackVarSize = int64(128 * 1024) // MaxImplicitStackVarSize = int64(64 * 1024) c := [128 * 1024 +1]byte{} d := make([]byte, 0, 64 * 1024 +1) Not sure how to verify this, but the assumption you can allocate megabytes on the stack seems wrong. The output of the escape analysis for arrays is different then the make statement: test/test.go:36:2: moved to heap: c Maybe an overlook because it is a bit sneaky?
      - masklinn 11mo ago
        > Not sure how to verify this, but the assumption you can allocate megabytes on the stack seems wrong. []byte{N: 0}
        deleted 11mo ago
        [deleted]
        Yokohiii 10mo ago
        doesn't make sense.
        10mo ago
9rx 11mo ago
> This seems to be a persistent source of confusion. Why? It is the same as in C. #include <stdio.h> #include <stdlib.h> 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 < s.len; i++) { printf("%d\n", s.data[i]); } free(s.data); }
- simiones 11mo ago
  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 semantics of the Go code always match the first version, even when the actual implementation is the second version.
  - 9rx 11mo ago
    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?
    - simiones 11mo ago
      Because people hear that Go supports value types and so is more efficient than Java because it can allocate on the stack*, and so they start thinking that they need to manage the stack. * Of course, in reality, Java also does escape analysis to allocate on the stack, though it's less likely to happen because of the lack of value types.
      - 9rx 11mo ago

by foldr 11mo ago

bonniesimon 11mo ago

Makes sense. I need to rewire how I think about Go. I should see it how I see JS.

Yokohiii 11mo ago

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 runtime with expensive stack grow calls. Go certainly tries to be smart about it with various strategies, but a rapid stack grow rate will have it's cost.

foldr 11mo ago
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).
- Yokohiii 11mo ago
  Escape analysis accounts for size, so it wouldn't even permit it. The initial stack size seems to be 2kb, a more on a few systems. So far I understand you can allocate a large local i.e. 8kb, that doesn't escape and grow the stack immediately. (Of course that adds up if you have a chain of calls with smaller allocs). So recursion is certainly not the only concern.
  - foldr 11mo ago
    For that to be a problem you either have to have one function that allocates an enormous number of non-escaping objects below the size limit (if the Go compiler doesn't take the total size of all a function's non-escaping allocations into account – I don't know), or a very long series of nested function calls, which in practice is only likely to arise if there are recursive calls.
    - Yokohiii 11mo ago
      I think we mix things up here. But be aware of my newbie knowledge. I am pretty sure the escape analysis doesn't affect the initial stack size. Escape analysis does determine where an allocation lives. So if your allocation is lower then what escape analysis considers heap and bigger then the initial stack size, the stack needs to grow. What I am certain about, is that I have runtime.newstack calls accounting for +20% of my benchmark times (go testing). My code is quite shallow (3-4 calls deep) and anything of size should be on the heap (global/preallocated) and the code has zero allocations. I don't use goroutines either, it might me I still make a mistake or it's the overhead from the testing benchmark. But this obviously doesn't seem to be anything super unusual.
      - foldr 11mo ago
        I don't know about your code, but in general, goroutine stacks are designed to start small and grow. There is nothing concerning about this. A call to runtime.newstack triggered by a large stack-allocated value would generally be cheaper than the corresponding heap allocation.
        Yokohiii 11mo ago
        I found my issue, I was creating a 256 item fixed array of a 2*uint8 struct in my code. That was enough to cause newstack calls. It now went down from varying 10% to roughly 1%. Oddly enough it didn't change the ns/op a bit. I guess some mix of workload related irrelevancy and inaccurate reporting or another oversight on my side.
- masklinn 11mo ago
  > Go won’t put large allocations on the stack even if escape analysis would permit it Depends what you mean by “large”. As of 1.24 Go will put slices several KB into the stack frame: make([]byte, 65536) Goes on the stack if it does not escape (you can see Go request a large stack frame) make([]byte, 65537) goes on the heap (Go calls runtime.makeslice). Interestingly arrays have a different limit: they respect MaxStackVarSize, which was lowered from 10MB to 128 KB in 1.24. If you use indexed slice literals gc does not even check and you can create megabyte-sized slices on the stack.
  - Yokohiii 11mo ago
    There is a option -smallframes that seems to be intended for conservative use cases. Below are the related configs and a test at what point they escape (+1). // -smallframes // ir.MaxStackVarSize = 64 * 1024 // ir.MaxImplicitStackVarSize = 16 * 1024 a := [64 * 1024 +1]byte{} b := make([]byte, 0, 16 * 1024 +1) // default // MaxStackVarSize = int64(128 * 1024) // MaxImplicitStackVarSize = int64(64 * 1024) c := [128 * 1024 +1]byte{} d := make([]byte, 0, 64 * 1024 +1) Not sure how to verify this, but the assumption you can allocate megabytes on the stack seems wrong. The output of the escape analysis for arrays is different then the make statement: test/test.go:36:2: moved to heap: c Maybe an overlook because it is a bit sneaky?
    - masklinn 11mo ago
      > Not sure how to verify this, but the assumption you can allocate megabytes on the stack seems wrong. []byte{N: 0}
      - deleted 11mo ago
        [deleted]
      - Yokohiii 10mo ago
        doesn't make sense.
        10mo ago

9rx 11mo ago

> This seems to be a persistent source of confusion. Why? It is the same as in C. #include <stdio.h> #include <stdlib.h> 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 < s.len; i++) { printf("%d\n", s.data[i]); } free(s.data); }

simiones 11mo ago
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 semantics of the Go code always match the first version, even when the actual implementation is the second version.
- 9rx 11mo ago
  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?
  - simiones 11mo ago
    Because people hear that Go supports value types and so is more efficient than Java because it can allocate on the stack*, and so they start thinking that they need to manage the stack. * Of course, in reality, Java also does escape analysis to allocate on the stack, though it's less likely to happen because of the lack of value types.
    - 9rx 11mo ago