Go Interface memory leakage

seemly Go doesn't release interface based pointers properly.

package main //interface memory leakage

import (
	"fmt"
	"runtime"
)

type Interface interface{ Method(v any) }
type Implementation struct{}

func (i *Implementation) Method(v any) {}

func main() {
	pages := Pages()
	fmt.Printf("First  Memory Usage: %dMB, expected 0\n", good())      // i:=&Implementation{}; i.Method(data)
	fmt.Printf("Second Memory Usage: %dMB, while expected 0\n", bad()) // var i Interface; i=&Implementation{}; i.Method(data)

	var xor byte //do somthing
	for j := 0; j < NUM_OF_PAGES; j++ {
		xor ^= pages[j][PAGE_SIZE-1]
	}
	print("xor: ", xor)
}

var data = "123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_"
var LOOP_SIZE = 3 * 1000 * 1000

const NUM_OF_PAGES = 10
const PAGE_SIZE = 1024 * 1024

func Pages() [][]byte {
	var pages [][]byte
	for j := 0; j < NUM_OF_PAGES; j++ {
		p := make([]byte, PAGE_SIZE)
		for i := 0; i < len(p); i++ {
			p[i] = 'A'
		}
		pages = append(pages, p)
	}
	return pages
}

func good() int64 {
	var m0, m1 runtime.MemStats
	runtime.ReadMemStats(&m0)

	i := &Implementation{} //good line
	for n := 0; n < LOOP_SIZE; n++ {
		i.Method(data)
	}

	//runtime.GC()
	runtime.ReadMemStats(&m1)
	return int64(m1.Alloc-m0.Alloc) / 1024 / 1024
}

func bad() int64 {
	var m0, m1 runtime.MemStats
	runtime.ReadMemStats(&m0)

	var i Interface       //bad line
	i = &Implementation{} //bad line
	for n := 0; n < LOOP_SIZE; n++ {
		i.Method(data)
	}

	//runtime.GC()
	runtime.ReadMemStats(&m1)
	return int64(m1.Alloc-m0.Alloc) / 1024 / 1024
}

https://go.dev/play/p/0zlbPxs6WCV

here the code is same, first time Go release pointers but second time, when we are using interface based pointer likely go doesn't handle memory properly.
I showed the good and bad syntax within the code, what's difference between two syntax? why second line wastes memory()?

• first: i:=&Implementation{}; i.Method(data)
• second: var i Interface; i=&Implementation{}; i.Method(data)

Also the output shows the problem:

First  Memory Usage: 0MB, expected 0
Second Memory Usage: 27MB, while expected 0  //However the number is variable but almost is different significantly

I expect same result between first and second try.

i := &Implementation{}

The first implementation is a pointer to a direct type.
No additional work needs to be done, because at compile time it is known which method needs to be invoked on the instance.

var i Interface
i = &Implementation{}

The second implementation boxes the pointer as an interface.
Because the value of i could be any value that satisfies the interface, it is not known which method needs to be executed, so more information needs to be stored in that variable.

When a pointer is boxed as an interface, it must store both the type of the pointer and the value of the pointer. So, an additional allocation must occur for that additional layer of indirection. Whether allocations are made on the heap or optimized onto the stack is determined by escape analysis.

Let's start by clarifying that there is no memory leak in your program - there are extra heap allocations in your bad case compared to your good case, but after a garbage collection, all that memory is released. That means there is no leak.

But there are certainly more heap allocations.

There are two ways to make your bad case have as much heap usage as the good case:

1. declare the data variable as type any:

   var data any = "123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_123456789_"
   

2. declare the argument type of the method as string:

   type Interface interface{ Method(v string) }
   type Implementation struct{}
   func (i *Implementation) Method(v string) {}
   

In both above cases, you eliminate the need to convert a string to and interface for every invocation of the method, so the compiler will not perform a heap allocation per invocation.

The real reason that the bad case allocates more on the heap, is that in the good case, the Go compiler knows the exact method implementation, and analysis it. It sees that the method does nothing, and avoids the call to the method altogether. In the bad case, it sees a method call on an interface, and the static analysis doesn't consider that the only possible implementation at that point is the struct Implementation, so it cannot determine that the method call doesn't have any effect.

If you change the implementation of Method to do something with the argument, like storing it in a package-scoped variable, then the compiler cannot optimise the method call away in good, and good and bad will both allocate the same amount on the heap.

As mentioned earlier, there is no memory leak - there are extra heap allocations.

Go compiler cannot predict the actual size of an interface, slice or map variable, so it allocates memory for it in the heap and not in the stack. Take a note, that a string in Go is a read-only slice of bytes.

Rus Cox has a great post about interfaces in Go
https://research.swtch.com/interfaces

Also you may be interested in William Kennedy's series of posts
https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-stacks-and-pointers.html