Update to parity-wasm 0.42 and allow to configure stack limits

[jiayihu]

This PR updates parity-wasm to 0.42 and allows to use env variable to set the stack limits. This is useful in applications like embedded where the available memory is very limited

Give it a check although the changes are trivial. I just got started with Rust and WASM recently 😄

[ithinuel]

The change to default value is not strictly required to achieve reasonable stack size on embedded targets.
A custom StackRecycler can be instantiated using StackRecycler::with_limits and the module started with NotStartedModuleRef::run_start_with_stack.

Note that you will likely require #243 to be able to load on a deeply embedded target.

[jiayihu]

Nice idea thanks! I'll take the chance to ask you how are you managing the stack size for a WASM module in MCU. I'm currently using a fork of wasmi where I limit the max pages to 1, since AFAIK, 1page of 64KB is the minimum size as defined in the standard. But 64KB is taking a lot in my STMF4 with only 128KB RAM in total.

[ithinuel]

It is indeed a requirement of the webassembly specs that memory instances are sized in unit of page-size defined as 64KiB.
In the proof of concept I worked on, the wasm module was build form a hand crafted wat source and did not require memory page.

I am not actively following wasm's news so there might be some work done or being done around that topic.
In the meantime my bet would be to use in the wasm modules a fork of wee_alloc where the PAGE_SIZE is adjusted to match what you set in your runtime.

The runtime would need to be built against a fork of memory_units to change the page size using cargo's patch feature but this is IMHO a bit too hacky.

I guess the “cleanest” approach to deviate from wasm's specs would be to modify MemoryInstance and ByteBuf so that it:

• all operations to ByteBuf::new , ByteBuf::realloc and ByteBuf::len are in Page unit rather than bytes.
• MemoryInstance relies on a trait (T: ByteBuf or T: MemoryBuffer) so that we can provide our own implementation of it in the ImporResolver.

But this will probably require some extra changes to ImportResolver to add an associated type for the MemoryInstance new parameter.
Embedded use-cases may be too much of a niche for the extra complexity it requires (see paritytech/parity-wasm#283 (comment)).

[jiayihu]

In the proof of concept I worked on, the wasm module was build form a hand crafted wat source and did not require memory page.

In my case, I was able to reduce the initial stack size by using the compiler flag link-arg=-zstack-size=16 as indicated here rustwasm/wasm-bindgen#1345. I also use the release optimizations:

[profile.release]
lto = true
opt-level = "z"

The final output is quite minimal for a simple module, especially if no heap is used. All rusty stuff like unwinding etc. is removed if not actually used. This allows me to compile from Rust without manually writing the wat file.

About the memory size spec, there's some discussion about it here: WebAssembly/spec#899.

Embedded use-cases may be too much of a niche for the extra complexity it requires (see paritytech/parity-wasm#283 (comment)).

Yup, I guess so. Working with embedded is always a struggle :) For the time being, I can live allowing 1 page of 64KB. Or one can avoid specifying the number of minimum pages in the WASM module, then the interpreter can allocate any custom default memory size.