fix(gnovm): zero-in Ops and Values correctly in (*Machine).Release

[thehowl]

$ go doc builtin.copy
package builtin // import "builtin"

func copy(dst, src []Type) int
    The copy built-in function copies elements from a source slice into a
    destination slice. (As a special case, it also will copy bytes from a string
    to a slice of bytes.) The source and destination may overlap. Copy returns
    the number of elements copied, which will be the minimum of len(src) and
    len(dst).

doing copy(m.Ops, opZeroed[:0]) is effectively a no-op, as len(src) == 0 and 0 items will be copied.

[piux2]

This will not zero the m.Ops and m.Values slice.

The opZeroed and valueZeroed arrays are fixed in size with a length of 1024. However, m.Ops and m.Values are slices, and their length could far exceed 1024. The copy() function, in this context, only zeroes out the first 1024 elements of the slice, leaving the remainder unchanged.

Here's a sample code that illustrates this behavior:
https://go.dev/play/p/JoShYG2Q8lf

Given the above, I don't see a significant advantage to zeroing out the entire slice.
A more effective approach might be to set the slice to nil, allowing the Go runtime to garbage collect the underlying arrays.

Here's why:

The VM machine operates within a transactional context, with its lifecycle managed by this context. The efficiency of interactions with gno.land is governed by the time it takes to process requests and responses within this context. The Go runtime handles the allocation and management of underlying slice memory far better than the manual methods we're attempting here.

Furthermore, there's an oversight: only m.Ops and m.Values are being considered for reset. The machine also retains m.Exprs, m.Stmts, m.Blocks, and m.Frames, all of which are slices. It's crucial to release these as well.