Why does converting `interface{}` back to slice cause an additional heap allocation?

func BenchmarkPool(b *testing.B) {
	b.ReportAllocs()
	p := sync.Pool{New: func() interface{} {
		return make([]byte, 1024)
	}}
	for i := 0; i < b.N; i++ {
		bts := p.Get().([]byte)
		p.Put(bts)
	}
}

This benchmark gives the following output in go1.19.5.

BenchmarkPool
BenchmarkPool-10    	47578498	        24.47 ns/op	      24 B/op	       1 allocs/op

When use *[]byte, things get different:

func BenchmarkPool(b *testing.B) {
	b.ReportAllocs()
	p := sync.Pool{New: func() interface{} {
		bts := make([]byte, 1024)
		return &bts
	}}
	for i := 0; i < b.N; i++ {
		bts := p.Get().(*[]byte)
		p.Put(bts)
	}
}

BenchmarkPool
BenchmarkPool-10    	142008002	         8.581 ns/op	       0 B/op	       0 allocs/op

It seems that convert interface{} back to slice cause an additional heap allocation.
Why does Go need this additional allocation? What's the design consideration under it?

A slice is meant to be "dynamic" in the sense that you allocate and discard the header and backing array as needed. When you pool the []byte value, the slice header is always copied, so all that is essentially reused is the backing array, and you need to allocate the extra 24 bytes for the header every time to return the slice to the pool. In other words, you can't reuse the slice header when you are only passing in a copy.

If you want the pool to store and reuse an entire slice value, then you want to use *[]byte because you need a pointer to the value you want to store in the pool. This would also allow you to return a differently sized slice value to the pool (possibly enlarged with append), which may or may not be desirable for your use case.

If you want only a statically sized buffer for reuse, then what you want is an array, or more specifically, a pointer to an array, which makes it much clearer what the expectations are of the pooled value.

func BenchmarkPool(b *testing.B) {
	b.ReportAllocs()
	p := sync.Pool{New: func() interface{} {
		return &[1024]byte{}
	}}
	for i := 0; i < b.N; i++ {
		buff := p.Get().(*[1024]byte)
		p.Put(buff)
	}
}

You can allocate a slice around that array as needed, and convert it back to an array when returning it to the pool.

It is not the conversion of any to []byte that causes allocation, it is the conversion of []byte to any that does. p.Put(bts) implicitly casts the argument bts to any before passing it to (*sync.Pool).Put. An interface as in GoGC 1.19 is implemented as a pair of pointers, one to the type metadata and one to the actual object, and it is the second pointer that escapes to the pool in this case that results in the slice object being allocated. This does not only hold for slice types but also any other non-pointer types.

For a pointer, such as a *[]byte, the compiler performs an optimisation that put its value directly into the iface struct, which removes the allocation of a *[]byte instance when converting to an interface. As a result, it is often recommended to put the pointer in pools instead of the struct themselves.