en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#703871a2 Enable the `useless_conversion` Clippy lint (#10838)* Enable the `useless_conversion` Clippy lintWe've got lots of types in Wasmtime and convert between them quite alot, but often over time conversions become unnecessary throughrefactorings or similar. This will hopefully enable us to clean up someconversions as they come up to try to have as few as possible ideally.* Review comments List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Tue, 27 May 2025 16:49:22 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#90ac295e Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Mon, 19 May 2025 16:40:55 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#a34427a3 Wasmtime: refactor the pooling allocator for components (#6835)* Wasmtime: Rename `IndexAllocator` to `ModuleAffinityIndexAllocator`We will have multiple kinds of index allocators soon, so clarify which one thisis.* Wasmtime: Introduce a simple index allocatorThis will be used in future commits refactoring the pooling allocator.* Wasmtime: refactor the pooling allocator for componentsWe used to have one index allocator, an index per instance, and give out Ntables and M memories to every instance regardless how many tables and memoriesthey need.Now we have an index allocator for memories and another for tables. An instanceisn't associated with a single instance, each of its memories and tables have anindex. We allocate exactly as many tables and memories as the instance actuallyneeds.Ultimately, this gives us better component support, where a component instancemight have varying numbers of internal tables and memories.Additionally, you can now limit the number of tables, memories, and coreinstances a single component can allocate from the pooling allocator, even ifthere is the capacity for that many available. This is to give embedders toolsto limit individual component instances and prevent them from hogging too muchof the pooling allocator's resources.* Remove unused fileMessed up from rebasing, this code is actually just inline in the indexallocator module.* Address review feedback* Fix benchmarks build* Fix ignoring test under miriThe `async_functions` module is not even compiled-but-ignored with miri, it iscompletely `cfg`ed off. Therefore we ahve to do the same with this test thatimports stuff from that module.* Fix doc links* Allow testing utilities to be unusedThe exact `cfg`s that unlock the tests that use these are platform and featuredependent and ends up being like 5 things and super long. Simpler to just allowunused for when we are testing on other platforms or don't have the compile timefeatures enabled.* Debug assert that the pool is empty on drop, per Alex's suggestionAlso fix a couple scenarios where we could leak indices if allocating an indexfor a memory/table succeeded but then creating the memory/table itself failed.* Fix windows compile errors List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 18 Aug 2023 21:23:47 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#b0939f66 Remove explicit `S` type parameters (#5275)* Remove explicit `S` type parameters This commit removes the explicit `S` type parameter on `Func::typed` and `Instance::get_typed_func`. Historical versions of Rust required that this be a type parameter but recent rustcs support a mixture of explicit type parameters and `impl Trait`. This removes, at callsites, a superfluous `, _` argument which otherwise never needs specification. * Fix mdbook examples List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Wed, 16 Nov 2022 05:04:26 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#84269041 bench: benchmark several common WASI scenarios (#5274)In order to properly understand the impact of providing thread-safe implmentations of WASI contexts (#5235), we need benchmarks that measure the current performance of WASI calls using Wiggle. This change adds several common WASI scenarios as WAT files (see `benches/wasi/*.wat`) and benchmarks them with `criterion`. Using `criterion`'s `iter_custom`, the WAT file runs the desired number of benchmark iterations internally and the total duration of the runs is divided to get the average time for each loop iteration. Why WAT? When compiling these benchmarks from Rust to `wasm32-wasi`, the output files are large, contain other WASI imports than the desired ones, and overall it is difficult to tell if we are measuring what we expect. By hand-writing the WAT, it is (slightly) more clear what each benchmark is doing. List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Wed, 16 Nov 2022 01:02:35 +0000 Andrew Brown <andrew.brown@intel.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#b14551d7 Refactor configuration for the pooling allocator (#5205)This commit changes the APIs in the `wasmtime` crate for configuring the pooling allocator. I plan on adding a few more configuration options in the near future and the current structure was feeling unwieldy for adding these new abstractions. The previous `struct`-based API has been replaced with a builder-style API in a similar shape as to `Config`. This is done to help make it easier to add more configuration options in the future through adding more methods as opposed to adding more field which could break prior initializations. List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 04 Nov 2022 20:06:45 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#82a31680 Use a `StoreOpaque` during backtraces for metadata (#4325)Previous to this commit Wasmtime would use the `GlobalModuleRegistry` when learning information about a trap such as its trap code, the symbols for each frame, etc. This has a downside though of holding a global read-write lock for the duration of this operation which hinders registration of new modules in parallel. In addition there was a fair amount of internal duplication between this "global module registry" and the store-local module registry. Finally relying on global state for information like this gets a bit more brittle over time as it seems best to scope global queries to precisely what's necessary rather than holding extra information. With the refactoring in wasm backtraces done in #4183 it's now possible to always have a `StoreOpaque` reference when a backtrace is collected for symbolication and otherwise Trap-identification purposes. This commit adds a `StoreOpaque` parameter to the `Trap::from_runtime` constructor and then plumbs that everywhere. Note that while doing this I changed the internal `traphandlers::lazy_per_thread_init` function to no longer return a `Result` and instead just `panic!` on Unix if memory couldn't be allocated for a stack. This removed quite a lot of error-handling code for a case that's expected to quite rarely happen. If necessary in the future we can add a fallible initialization point but this feels like a better default balance for the code here. With a `StoreOpaque` in use when a trap is being symbolicated that means we have a `ModuleRegistry` which can be used for queries and such. This meant that the `GlobalModuleRegistry` state could largely be dismantled and moved to per-`Store` state (within the `ModuleRegistry`, mostly just moving methods around). The final state is that the global rwlock is not exclusively scoped around insertions/deletions/`is_wasm_trap_pc` which is just a lookup and atomic add. Otherwise symbolication for a backtrace exclusively uses store-local state now (as intended). The original motivation for this commit was that frame information lookup and pieces were looking to get somewhat complicated with the addition of components which are a new vector of traps coming out of Cranelift-generated code. My hope is that by having a `Store` around for more operations it's easier to plumb all this through. List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Mon, 27 Jun 2022 20:24:59 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#15bb0c69 Remove the `ModuleLimits` pooling configuration structure (#3837)* Remove the `ModuleLimits` pooling configuration structure This commit is an attempt to improve the usability of the pooling allocator by removing the need to configure a `ModuleLimits` structure. Internally this structure has limits on all forms of wasm constructs but this largely bottoms out in the size of an allocation for an instance in the instance pooling allocator. Maintaining this list of limits can be cumbersome as modules may get tweaked over time and there's otherwise no real reason to limit the number of globals in a module since the main goal is to limit the memory consumption of a `VMContext` which can be done with a memory allocation limit rather than fine-tuned control over each maximum and minimum. The new approach taken in this commit is to remove `ModuleLimits`. Some fields, such as `tables`, `table_elements` , `memories`, and `memory_pages` are moved to `InstanceLimits` since they're still enforced at runtime. A new field `size` is added to `InstanceLimits` which indicates, in bytes, the maximum size of the `VMContext` allocation. If the size of a `VMContext` for a module exceeds this value then instantiation will fail. This involved adding a few more checks to `{Table, Memory}::new_static` to ensure that the minimum size is able to fit in the allocation, since previously modules were validated at compile time of the module that everything fit and that validation no longer happens (it happens at runtime). A consequence of this commit is that Wasmtime will have no built-in way to reject modules at compile time if they'll fail to be instantiated within a particular pooling allocator configuration. Instead a module must attempt instantiation see if a failure happens. * Fix benchmark compiles * Fix some doc links * Fix a panic by ensuring modules have limited tables/memories * Review comments * Add back validation at `Module` time instantiation is possible This allows for getting an early signal at compile time that a module will never be instantiable in an engine with matching settings. * Provide a better error message when sizes are exceeded Improve the error message when an instance size exceeds the maximum by providing a breakdown of where the bytes are all going and why the large size is being requested. * Try to fix test in qemu * Flag new test as 64-bit only Sizes are all specific to 64-bit right now List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 25 Feb 2022 15:11:51 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#7ce46043 Add guard pages to the front of linear memories (#2977)* Add guard pages to the front of linear memories This commit implements a safety feature for Wasmtime to place guard pages before the allocation of all linear memories. Guard pages placed after linear memories are typically present for performance (at least) because it can help elide bounds checks. Guard pages before a linear memory, however, are never strictly needed for performance or features. The intention of a preceding guard page is to help insulate against bugs in Cranelift or other code generators, such as CVE-2021-32629. This commit adds a `Config::guard_before_linear_memory` configuration option, defaulting to `true`, which indicates whether guard pages should be present both before linear memories as well as afterwards. Guard regions continue to be controlled by `{static,dynamic}_memory_guard_size` methods. The implementation here affects both on-demand allocated memories as well as the pooling allocator for memories. For on-demand memories this adjusts the size of the allocation as well as adjusts the calculations for the base pointer of the wasm memory. For the pooling allocator this will place a singular extra guard region at the very start of the allocation for memories. Since linear memories in the pooling allocator are contiguous every memory already had a preceding guard region in memory, it was just the previous memory's guard region afterwards. Only the first memory needed this extra guard. I've attempted to write some tests to help test all this, but this is all somewhat tricky to test because the settings are pretty far away from the actual behavior. I think, though, that the tests added here should help cover various use cases and help us have confidence in tweaking the various `Config` settings beyond their defaults. Note that this also contains a semantic change where `InstanceLimits::memory_reservation_size` has been removed. Instead this field is now inferred from the `static_memory_maximum_size` and guard size settings. This should hopefully remove some duplication in these settings, canonicalizing on the guard-size/static-size settings as the way to control memory sizes and virtual reservations. * Update config docs * Fix a typo * Fix benchmark * Fix wasmtime-runtime tests * Fix some more tests * Try to fix uffd failing test * Review items * Tweak 32-bit defaults Makes the pooling allocator a bit more reasonable by default on 32-bit with these settings. List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 18 Jun 2021 14:57:08 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#035d541f add docs List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 04 Jun 2021 21:04:14 +0000 Pat Hickey <pat@moreproductive.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/benches/thread_eager_init.rs#2a4c51b7 switch eager vs lazy instantiation to a criterion bench List of files: /wasmtime-44.0.1/benches/thread_eager_init.rs Fri, 04 Jun 2021 19:24:44 +0000 Pat Hickey <pat@moreproductive.org>