allocating large chunk of bytes

[failfmi]

While trying to benchmark the runtime with 10_000 System.remark extrinsics in Execute_block, the following error occurs:

failed to allocate: allocating: bumping: cannot grow linear memory: from 4096 pages to 8192 pages

Even if we increase the wazero instance wasm pages to more (8192, or even 16384), a new error occurs:

running runtime function: order from size: requested allocation too large, requested 67108864, max possible allocations: 33554432 (recovered by wazero)

It seems that it tries to allocate a big chunk, which is more than the maximum allowed (33554432).

Most probably GC related.

[radkomih]

todo

1. test multiple calls to a simple runtime function that heap allocates and frees memory (trigger the gc manually):

• fixed a gc issue when opt levels is 0:

...
.runtime.alloc(i32,i32,i32) i32
.runtime.alloc(i32,i32,i32) i32
.runtime.alloc(i32,i32,i32) i32
.runtime.hashmapMake(i32,i32,i32,i32,i32) i32
.github.com/LimeChain/gosemble/primitives/types.BuildMetadataTypesIdsMap(i32) i32
.(*github.com/LimeChain/gosemble/primitives/types.MetadataTypeGenerator).ClearMetadata(i32,i32)

• single byte - the gc works as expected
• slices, maps, structs -

2. test the metadata runtime function:

• it appears that there is a memory issue, it might not be an actual memory leak, but a global that is constantly adding stuff in memory
• use an older commit, before the metadata refactor - it appears to be working fine
• the "goscale" codec could be contributing to the problem, since the second error appears similar to a previous one: hitting the max possible allocation size when U8 encoding with the custom gc