@Till Schneidereit @Alex Crichton @Dan Gohman I would like to kick start a conversation about adding support for host-managed memory. This is quite important for our use case at DFINITY. In particular, we need to ensure that either 1) once allocated, the memory does not move or 2) if the memory needs to be moved we need to know when and where. We also need to know when memory.grow
occurs.
Andreas Rossberg explored this in wasm-c-api
:
https://github.com/WebAssembly/wasm-c-api/blob/host-mem/example/mmap.cc#L290
We, at DFINITY (@Krzysztof Woś @Maciej Kot ), would like to contribute this feature to wasmtime. I was experimenting with this while back (the code is horribly outdated by now) and the plumbing to make it work wasn't very complicated. The interesting part would be designing a clean API.
What is your thinking on this? What would be a good way to proceed?
Thank you for offering to contribute this—it sounds like a very useful feature not just for your use case!
@Peter Huene, I'd also like your thoughts on this, from an API design perspective.
Sounds like a reasonable feature to me! My first thought in terms of implementation might be to have something like an unsafe trait HostMemory
along with Memory::new_host(impl HostMemory)
we'd then document all the various contracts necessary to uphold in trait HostMemory
and that'd have all the hooks that wasm needs and the implementation internally can do whatever it likes.
I think that makes sense to me as well for the Rust side. For the C API, we can either have extension functions that mirror the trait or, if Andreas is already thinking about what the C contract looks like, we would conform to that.
Created a PR, please let me know your thoughts
https://github.com/bytecodealliance/wasmtime/pull/1400
Last updated: Dec 23 2024 at 13:07 UTC