feat: add ability to configure static memory size#763
Conversation
|
Nice! What happens if this limit is exceeded? And is it only upon instantiation? |
|
If the limit is exceeded then it switches to dynamic memory, where more memory is allocated and the old memory is copied over - so there is some performance downside to growing memory at that point. More information here: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size |
|
|
||
| /// Limit the size of the memory allocated up-front when | ||
| /// instantiating a module | ||
| pub fn with_static_memory_size(mut self, size: u64) -> Self { |
There was a problem hiding this comment.
Considering the potential performance implications, and the big warnings from the underlaying wasmtime function's documentation, maybe it would be worth it to add a link to https://docs.wasmtime.dev/api/wasmtime/struct.Config.html#method.static_memory_maximum_size in this function's documentation.
Just so people not aware don't accidently change that setting without understanding
|
I just opened #764, which solves the same problem in a more general way |
An alternative to #763, this PR allows an initial `wasmtime::Config` to be passed in when building a plugin. Some of these values may be overwritten by the Extism runtime, but it allows for things like static memory size and other low-level details to be handled directly instead of us having to wrap every option ourselves.
|
Closing this after merging #764 |
3 participants
This makes it possible to configure the amount of memory that's allocated up front when instantiating a plugin.
Also adds a default static memory size of 4GB to the C API.