The Go compiler makes use of escape analysis, a potent optimization technique, to better handle memory allocation and management. An object’s lifetime is examined in order to ascertain whether or not it can be safely allocated on the stack rather than the heap, which is the central idea behind escape analysis. Allocating an object on the stack is preferable to allocating it on the heap because the stack is a more efficient data structure.
The Go compiler takes care of doing the escape analysis for you automatically. If a function’s variables or data structures are being accessed outside of the function’s scope, the algorithm performing the escape analysis will flag it. A variable is said to have “escaped” when it is used outside of the function in which it was defined. In this case, the compiler will allocate it on the heap.
Here’s an example to illustrate the concept of escape analysis:
package main
import "fmt"
func main() {
x := 10
y := square(&x)
fmt.Println(*y)
}
func square(x *int) *int {
z := (*x) * (*x)
return &z
}Here we define the square function, which accepts an integer pointer and returns the same type of reference. From main, we invoke square, passing in the address of the integer variable x. For the purpose of returning the square of the value pointed to by x, we create an integer variable z on the stack and use it to do the calculation inside square.
However, since z is being passed by reference to main, it will be free to leave the square function when it is returned. To guarantee that z’s memory is still available after square returns, the compiler will allocate it on the heap rather than the stack.
Using the -gcflags “-m” option during compilation will print information about memory allocations, allowing us to observe the effect of escape analysis on memory usage.
$ go build -gcflags "-m" main.go
.\main.go:11:6: can inline square
.\main.go:7:13: inlining call to square
.\main.go:8:13: inlining call to fmt.Println
.\main.go:8:13: ... argument does not escape
.\main.go:8:14: *y escapes to heap
.\main.go:11:13: x does not escape
.\main.go:12:2: moved to heap: zThe output reveals that while the argument to square does not escape, the variable z does and ends up on the heap.package main
import "fmt"
func main() {
var p *int
fmt.Println(*foo(p))
}
func foo(p *int) *int {
fmt.Println(p) // just printing the value to suppress warning, before first use (SA4009)
x := 10
p = &x
return p
}An integer pointer (int) is passed into the function foo defined here, and the same type (int) is returned. A stack-based integer variable x is created within foo, and its address is then assigned to the pointer p, which is then returned. We pass a null pointer to foo when we call it from main, so p will always be null.
However, if the address of x is returned via p, the variable x will be free to leave foo. As a result, the compiler will make a heap allocation for x rather than using the stack.
$ go build -gcflags "-m" main.go
# command-line-arguments
.\main.go:11:13: inlining call to fmt.Println
.\main.go:7:13: inlining call to fmt.Println
.\main.go:10:10: leaking param: p
.\main.go:12:2: moved to heap: x
.\main.go:11:13: ... argument does not escape
.\main.go:7:13: ... argument does not escape
.\main.go:7:14: *foo(p) escapes to heapThe output demonstrates that x is allocated on the heap while the argument to foo remains confined within the call.
A crucial part of Go’s optimization toolkit, escape analysis reduces programs demands on RAM to boost their speed and efficiency. The compiler can improve the performance of the program by determining when it is safe to allocate memory on the stack rather than the heap, thus avoiding costly memory allocations and deallocations and decreasing the overhead of garbage collection.
To sum up, the Go compiler uses a potent optimization technique called escape analysis to figure out for itself whether or not objects can be allocated on the stack or the heap. By reducing the need for memory allocations and deallocations, the technique helps programs run faster.
