Changes in decommit_queue.rs

0afe5fc7 - Handle more failures deallocating pooled memroy (#12888)

Mon, 30 Mar 2026 23:50:53 +0000

Handle more failures deallocating pooled memroy (#12888)* Handle more failures deallocating pooled memroyThis commit replaces a few panics in the pooling allocator witherror-handling of what happens at runtime. This is a defense-in-depthmeasure to ensure that the pooling allocator doesn't panic at runtimeand instead handles errors where possible.The first path fixed is in `deallocate_memory` where resetting a slotcould result in an error being returned on non-Linux platforms, and ifthis happened it would cause a panic. The error is instead gracefullyhandled by continuing slot deallocation but avoiding putting the imageitself back into memory. This leaves the slot in an `Unknown` statewhich is already handled by resetting the state upon reuse. The mainconsequence here is that future statistics about resident bytes won't beaccurate, but these are already inaccurate on non-Linux platformsanyway, so there's no loss.The second path fixes is in flushing a `DecommitQueue` where`decommit_pages` was asserted to succeed. Instead now the error ishandled by dropping all images and leaving slots in an `Unknown` state,similar to `deallocate_memory`.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

c33c8b8d - Add some more metrics to the pooling allocator (#11789)

Tue, 07 Oct 2025 04:14:04 +0000

Add some more metrics to the pooling allocator (#11789)* Add some more metrics to the pooling allocatorThis commit adds a few more metrics to the `PoolingAllocatorMetrics`type along the lines of accounting for more items as well as the unusedslots in the pooling allocator. Notably the count of unused memory andtable slots is exposed along with the number of bytes which are keptresident in these slots despite them not being in use. This involved abit of plumbing to thread around the number of bytes that are actuallykept resident to some more locations but is otherwise a prettystraightforward plumbing of accounting information we already hadinternally.* Fix configured build* Add some docs* Only run new test on Linux* Try to fix ASANprtest:full* Shrink pooling size in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

838ed2d0 - Enable `allow_attributes_without_reason` (#11195)

Mon, 07 Jul 2025 21:52:03 +0000

Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I'venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don't have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

bdd78422 - Wasmtime: Implement the custom-page-sizes proposal (#8763)

Wed, 12 Jun 2024 21:46:42 +0000

Wasmtime: Implement the custom-page-sizes proposal (#8763)* Wasmtime: Implement the custom-page-sizes proposalThis commit adds support for the custom-page-sizes proposal to Wasmtime:https://github.com/WebAssembly/custom-page-sizesI've migrated, fixed some bugs within, and extended the `*.wast` tests for thisproposal from the `wasm-tools` repository. I intend to upstream them into theproposal shortly.There is a new `wasmtime::Config::wasm_custom_page_sizes_proposal` method toenable or disable the proposal. It is disabled by default.Our fuzzing config has been updated to turn this feature on/off as dictated bythe arbitrary input given to us from the fuzzer.Additionally, there were getting to be so many constructors for`wasmtime::MemoryType` that I added a builder rather than add yet anotherconstructor.In general, we store the `log2(page_size)` rather than the page sizedirectly. This helps cut down on invalid states and properties we need toassert.I've also intentionally written this code such that supporting any power of twopage size (rather than just the exact values `1` and `65536` that are currentlyvalid) will essentially just involve updating `wasmparser`'s validation andremoving some debug asserts in Wasmtime.* Update error string expectation* Remove debug logging* Use a right shift instead of a division* fix error message expectation again* remove page size from VMMemoryDefinition* fix size of VMMemoryDefinition again* Only dynamically check for `-1` sentinel for 1-byte page sizes* Import functions that are used a few times* Better handle overflows when rounding up to the host page sizePropagate errors instead of returning a value that is not actually a rounded upversion of the input.Delay rounding up various config sizes until runtime instead of eagerly doing itat config time (which isn't even guaranteed to work, so we already had to have abackup plan to round up at runtime, since we might be cross-compiling wasm ornot have the runtime feature enabled).* Fix some anyhow and nostd errors* Add missing rounding up to host page size at runtime* Add validate feature to wasmparser dep* Add some new rounding in a few places, due to no longer rounding in config methods* Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` testThe point of the test is to ensure that we hit the limiter, so just cancel theallocation from the limiter, and otherwise avoid MIRI attempting to allocate abunch of memory after we hit the limiter.* prtest:full* Revert "Avoid actually trying to allocate the whole address space in the `massive_64_bit_still_limited` test"This reverts commit ccfa34a78dd3d53e49a6158ca03077d42ce8bcd7.* miri: don't attempt to allocate more than 4GiB of memoryIt seems that rather than returning a null pointer from `std::alloc::alloc`,miri will sometimes choose to simply crash the whole program.* remove duplicate prelude import after rebasing List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

0e9121da - Fix some typos (#8641)

Thu, 16 May 2024 23:21:22 +0000

Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs

e1f8b9b7 - Wasmtime(pooling allocator): Batch decommits (#8590)

Tue, 14 May 2024 00:23:17 +0000

Wasmtime(pooling allocator): Batch decommits (#8590)This introduces a `DecommitQueue` for batching decommits together in the poolingallocator:* Deallocating a memory/table/stack enqueues their associated regions of memory for decommit; it no longer immediately returns the associated slot to the pool's free list. If the queue's length has reached the configured batch size, then we flush the queue by running all the decommits, and finally returning the memory/table/stack slots to their respective pools and free lists.* Additionally, if allocating a new memory/table/stack fails because the free list is empty (aka we've reached the max concurrently-allocated limit for this entity) then we fall back to a slow path before propagating the error. This slow path flushes the decommit queue and then retries allocation, hoping that the queue flush reclaimed slots and made them available for this fallback allocation attempt. This involved defining a new `PoolConcurrencyLimitError` to match on, which is also exposed in the public embedder API.It is also worth noting that we *always* use this new decommit queue now. Tokeep the existing behavior, where e.g. a memory's decommits happen immediatelyon deallocation, you can use a batch size of one. This effectively disablesqueueing, forcing all decommits to be flushed immediately.The default decommit batch size is one.This commit, with batch size of one, consistently gives me an increase on`wasmtime serve`'s requests-per-second versus its parent commit, as measured by`benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35KRPS on the parent commit. This is quite puzzling to me. I was expecting nochange, and hoping there wouldn't be a regression. I was not expecting a speedup. I cannot explain this result at this time.prtest:fullCo-authored-by: Jamey Sharp List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/instance/allocator/pooling/decommit_queue.rs