Christoph Herzog

We will be able to use the functionality from https://github.com/wasmerio/wasmer/pull/4263 for this.

Hopefully @john-sharratt can provide more context. Regarding the stack pointer, I think that is provided only in `wasix` builds.

For capturing the stack to work the module needs to be compiled with wasix (see cargo-wasix / wasix.org), because it uses asyncify to enable unwinding and rewinding.

Just to clarify, `cargo wasix build` will run `wasm-opt` with the asyncify step automatically. No need to do that manually.

Should check if this is still relevant.

This is not a bug, this is expected behaviour. Wasmer needs to reserve about 4GB of memory space per instance (32 bit), plus a 2GB guard page. So that's roughly...

Just an addendum: the wasmer-wasix crate has an async_threading feature, which makes it possible to pause instances persist, their state, and resume them later. With some modifications it would be...

And a second addendum: I just leanred that there is actually a different compilation mode where guard pages are not required, and where each memory access is bounds checked, which...

> i don't see memory being consumed in htop, is that expected? Yeah, that's expected. Memory isn't actually consumed from the OS perspective until it is actively used, but the...

> unless i have a bug (entirely possible) the benchmark that triggers the error is creating and dropping instances in a tight loop, so why does that cause memory to...