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 havewasmtime_memory_grow()
so why notwasmtime_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.
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 havewasmtime_memory_grow()
so why notwasmtime_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>
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?
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: Nov 22 2024 at 16:03 UTC