Go Derleyicisi Slice Tahsislerini Yığında Yapıyor

This Go Blog post explains compiler-level work across recent Go releases aimed at reducing heap allocations by moving more slice backing-store allocations onto the stack. The classic pattern of growing a slice via repeated append calls causes multiple heap allocations (sizes 1, 2, 4, 8...) as the backing store is repeatedly replaced, each old store becoming garbage that burdens the GC and hurts cache locality. The article shows that a constant-size make() call could already be stack-allocated by the Go 1.24 compiler, but this optimization broke down once the requested capacity came from a variable rather than a literal constant.

Go 1.25 closes that gap by having the compiler speculatively allocate a small (32-byte) backing store on the stack for variable-sized make calls, falling back to the heap only when the requested size exceeds that budget. Go 1.26 extends the same idea directly to append itself: the first few appended elements can use a stack-allocated backing store instead of triggering the usual escalating heap allocations, eliminating most of the allocation and garbage-collection overhead seen during a slice's early growth phase.

For engineers, the practical takeaway is that small, non-escaping slices can now benefit from these optimizations automatically, without any code changes, simply by upgrading the Go toolchain. The article notes an important limit, however: slices that escape (e.g., returned from a function) still cannot be stack-allocated, since the stack frame is gone once the function returns—setting up further discussion on how that case might be addressed.