Investigate the use of other allocators within modules

[AndrewSisley]

And the auto-clearing of module memory.

I am doubtful that this can be handled within the host alone, as whilst the host can overwrite the memory in many situations. Depending on how/where the memory was allocated, it may be protected by the module runtime, and even then de-allocing it from the host may not 'free' it for use within the module runtime as it may still think it is occupied (unless the module actively forgets it). Be careful with these aspects when testing.

[jsimnz]

module runtime, and even then de-allocing it from the host may not 'free' it for use within the module runtime as it may still think it is occupied

Completely clearing the module memory from the host would also remove any state related to current allocations (runtime state) - so it should in theory run from a completely blank empty slate.

The one thing to note is the current design instanciates modules with the input params on module startup, and wipping the memory of the module would wipe the input param state. The original design had the input params as args to the transform func. Just something to keep in mind when thinking through the allocator/memory stuff.

[jsimnz]

references:
"Popular" rust wasm allocator (possible leaking): https://github.com/rustwasm/wee_alloc
"Less popular" (WIP) rust wasm alloctor: https://github.com/Craig-Macomber/lol_alloc

interesting post about wasm/allocations/module size:
https://nickb.dev/blog/avoiding-allocations-in-rust-to-shrink-wasm-modules/