4 ms·

> 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 K

by 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 11mo ago
    doesn't make sense.
    - masklinn 10mo ago
      And yet it does: https://godbolt.org/z/h9GW5v3YK https://godbolt.org/z/h9GW5v3YK And creates an on-stack slice whose size is only limited by Go's 1GB limit on individual stack frames: https://godbolt.org/z/rKzo8jre6 https://godbolt.org/z/rKzo8jre6 https://godbolt.org/z/don99e9cn https://godbolt.org/z/don99e9cn
      - Yokohiii 10mo ago
        Yea with more context it suddenly makes sense :p Interesting, [...] syntax works here as expected. So escape analysis simply doesn't look at the element list.

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 11mo ago
  doesn't make sense.
  - masklinn 10mo ago
    And yet it does: https://godbolt.org/z/h9GW5v3YK https://godbolt.org/z/h9GW5v3YK And creates an on-stack slice whose size is only limited by Go's 1GB limit on individual stack frames: https://godbolt.org/z/rKzo8jre6 https://godbolt.org/z/rKzo8jre6 https://godbolt.org/z/don99e9cn https://godbolt.org/z/don99e9cn
    - Yokohiii 10mo ago
      Yea with more context it suddenly makes sense :p Interesting, [...] syntax works here as expected. So escape analysis simply doesn't look at the element list.