Wasmtime: generalize async_stack_zeroing knob to cover initialization#10027
Wasmtime: generalize async_stack_zeroing knob to cover initialization#10027fitzgen merged 4 commits intobytecodealliance:mainfrom
async_stack_zeroing knob to cover initialization#10027Conversation
This commit moves the knob from the `PoolingInstanceAllocatorConfig` to the regular `Config` and now controls both whether stacks are zeroed before reuse and whether they are zeroed before the initial use. The latter doesn't matter usually, since anonymous mmaps are already zeroed so we don't have to do anything there, but for no-std environments it is the difference between manually zeroing the stack or simply using unininitialized memory.
Label Messager: wasmtime:configIt looks like you are changing Wasmtime's configuration options. Make sure to
DetailsTo modify this label's message, edit the To add new label messages or remove existing label messages, edit the |
Grabbing the latest patch release since it contains the latest fixes. This change also mirrors the `async_stack_zeroing` change, introduced in bytecodealliance/wasmtime#10027
* Bump wasmtime to v30.0.2 Grabbing the latest patch release since it contains the latest fixes. This change also mirrors the `async_stack_zeroing` change, introduced in bytecodealliance/wasmtime#10027 * Document `async_stack_zeroing` at the engine level * Update nightly version * Bump `yard-rustdoc` * Strip the nightly version after reading it To ensure no unwanted new lines or spaces are included as part of interpolation
This commit moves the knob from the
PoolingInstanceAllocatorConfigto the regularConfigand now controls both whether stacks are zeroed before reuse and whether they are zeroed before the initial use. The latter doesn't matter usually, since anonymous mmaps are already zeroed so we don't have to do anything there, but for no-std environments it is the difference between manually zeroing the stack or simply using unininitialized memory.