Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source
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.
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.
moul
commented
11 months ago
Originally posted by @piux2 in https://github.com/gnolang/gno/issues/894#issuecomment-1668876811
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.