Stream: git-wasmtime

Topic: wasmtime / issue #9572 Add a `wasmtime::Memory::discard` ...


view this post on Zulip Wasmtime GitHub notifications bot (Nov 07 2024 at 18:59):

fitzgen edited issue #9572:

Feature

While memory.discard isn't here yet, we could use a way to shrink Wasm module memory without having to reinitialise it. I propose a Wasmtime function to simply shrink the linear memory.

Context

I have a C library with which I can make native host programs that call Wasm reactor module functions sequentially using Wasmtime and the modules have access to one C function to send commands back to the host. Lots of things can be done this way, as it is I could even shrink memory by reinitialising it, but there could be a better way. In many cases I can even see the exact contents of a module's heap from the host so I can see how much free space there is at the end of the heap.

Benefit

In some situations a Wasm module can temporarily need lots of memory. As it is we're not really able to then release that memory without reinitialising the module. If we had a way to simply directly shrink the linear memory buffer to a given number of pages that would go a long way. In my case the host could shrink it either by user input, its own determination (many of my modules use an allocator that allows the host to clearly identify all the allocations on the module's heap) or the module could even send a message to the host requesting for the memory to be shrank either right away or after wasmtime_func_call() is done.

Implementation

I think a simple function (in terms of the C API, I don't know about the Rust side) like wasmtime_error_t *wasmtime_memory_shrink(wasmtime_context_t *store, const wasmtime_memory_t *memory, uint64_t new_size, uint64_t *prev_size) would do nicely, and it would very simply just shrink the linear memory buffer. We have wasmtime_memory_grow() so why not wasmtime_memory_shrink().

Alternatives

Without this I would wait for the module's function to be done executing, copy its memory up to the new size somewhere else, reinitialise the module so it has a new memory, grow it to the desired size and copy the copy back into the module's new linear memory. My proposal would make things smoother. Even better if it's something effectively just like calling realloc() on a buffer so that shrinking regularly by a page or two would happen in no time.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 07 2024 at 19:01):

fitzgen edited issue #9572:

Edited by @fitzgen: This issue has evolved. For the up-to-date description, see this comment


<details> <summary>Original Issue Text</summary>

Feature

While memory.discard isn't here yet, we could use a way to shrink Wasm module memory without having to reinitialise it. I propose a Wasmtime function to simply shrink the linear memory.

Context

I have a C library with which I can make native host programs that call Wasm reactor module functions sequentially using Wasmtime and the modules have access to one C function to send commands back to the host. Lots of things can be done this way, as it is I could even shrink memory by reinitialising it, but there could be a better way. In many cases I can even see the exact contents of a module's heap from the host so I can see how much free space there is at the end of the heap.

Benefit

In some situations a Wasm module can temporarily need lots of memory. As it is we're not really able to then release that memory without reinitialising the module. If we had a way to simply directly shrink the linear memory buffer to a given number of pages that would go a long way. In my case the host could shrink it either by user input, its own determination (many of my modules use an allocator that allows the host to clearly identify all the allocations on the module's heap) or the module could even send a message to the host requesting for the memory to be shrank either right away or after wasmtime_func_call() is done.

Implementation

I think a simple function (in terms of the C API, I don't know about the Rust side) like wasmtime_error_t *wasmtime_memory_shrink(wasmtime_context_t *store, const wasmtime_memory_t *memory, uint64_t new_size, uint64_t *prev_size) would do nicely, and it would very simply just shrink the linear memory buffer. We have wasmtime_memory_grow() so why not wasmtime_memory_shrink().

Alternatives

Without this I would wait for the module's function to be done executing, copy its memory up to the new size somewhere else, reinitialise the module so it has a new memory, grow it to the desired size and copy the copy back into the module's new linear memory. My proposal would make things smoother. Even better if it's something effectively just like calling realloc() on a buffer so that shrinking regularly by a page or two would happen in no time.

</details>

view this post on Zulip Wasmtime GitHub notifications bot (Nov 07 2024 at 19:02):

fitzgen commented on issue #9572:

I've updated the issue title to reflect the new intentions here.

@Photosounder are you interested in trying your hand at implementing this feature?

view this post on Zulip Wasmtime GitHub notifications bot (Nov 07 2024 at 19:19):

Photosounder commented on issue #9572:

I've updated the issue title to reflect the new intentions here.

@Photosounder are you interested in trying your hand at implementing this feature?

Thanks, but I don't know Rust at all and like I said the topic of dealing with OS pages is new to me so it's best left to someone competent :wink:


Last updated: Dec 23 2024 at 12:05 UTC