Changes in instance.rs

6ac02e10 - Optimize MIRI execution time in CI (#10038)

Fri, 17 Jan 2025 15:33:11 +0000

Optimize MIRI execution time in CI (#10038)* Optimize MIRI execution time in CI* Disable Cranelift optimizations and use single_pass register allocation by default.* Ignore a number of tests that are compiling wasm which we generally don't want to do under MIRI.* Fix CI build List of files: /wasmtime-44.0.1/tests/all/instance.rs

1f812627 - Test Pulley on CI on 32-bit architectures (#9745)

Fri, 06 Dec 2024 20:57:40 +0000

Test Pulley on CI on 32-bit architectures (#9745)This commit extends our CI for i686 and armv7 to test the Pulleybackend, namely the full `*.wast` test suite as well as the `wasmtime`crate itself. Note that many `*.wast` tests are still expected to failat this time.This involved fixing a number of 32-vs-64 bit issues throughout the testsuite in various location in this commit. List of files: /wasmtime-44.0.1/tests/all/instance.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/tests/all/instance.rs

906ea017 - Use bytes for maximum size of linear memory with pooling (#8628)

Fri, 17 May 2024 04:06:39 +0000

Use bytes for maximum size of linear memory with pooling (#8628)* Use bytes for maximum size of linear memory with poolingThis commit changes configuration of the pooling allocator to use abyte-based unit rather than a page based unit. The previous`PoolingAllocatorConfig::memory_pages` configuration option configuresthe maximum size that a linear memory may grow to at runtime. This is animportant factor in calculation of stripes for MPK and is also acoarse-grained knob apart from `StoreLimiter` to limit memoryconsumption. This configuration option has been renamed to`max_memory_size` and documented that it's in terms of bytes rather thanpages as before.Additionally the documented constraint of `max_memory_size` must besmaller than `static_memory_bound` is now additionally enforced as aminor clean-up as part of this PR as well.* Review comments* Fix benchmark build List of files: /wasmtime-44.0.1/tests/all/instance.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/tests/all/instance.rs

a34427a3 - Wasmtime: refactor the pooling allocator for components (#6835)

Fri, 18 Aug 2023 21:23:47 +0000

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/tests/all/instance.rs

c0bb341d - Run some tests in MIRI on CI (#6332)

Wed, 03 May 2023 21:02:33 +0000

Run some tests in MIRI on CI (#6332)* Run some tests in MIRI on CIThis commit is an implementation of getting at least chunks of Wasmtimeto run in MIRI on CI. The full test suite is not possible to run in MIRIbecause MIRI cannot run Cranelift-produced code at runtime (aka itdoesn't support JITs). Running MIRI, however, is still quite valuable ifwe can manage it because it would have trivially detectedGHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of thisPR is to select a subset of the test suite to execute in CI under MIRIand boost our confidence in the copious amount of `unsafe` code inWasmtime's runtime.Under MIRI's default settings, which is to use the [StackedBorrows][stacked] model, much of the code in `Instance` and `VMContext`is considered invalid. Under the optional [Tree Borrows][tree] model,however, this same code is accepted. After some [extremely helpfuldiscussion][discuss] on the Rust Zulip my current conclusion is thatwhat we're doing is not fundamentally un-sound but we need to model itin a different way. This PR, however, uses the Tree Borrows model forMIRI to get something onto CI sooner rather than later, and I hope tofollow this up with something that passed Stacked Borrows. Additionallythat'll hopefully make this diff smaller and easier to digest.Given all that, the end result of this PR is to get 131 separate unittests executing on CI. These unit tests largely exercise the embeddingAPI where wasm function compilation is not involved. Some tests compilewasm functions but don't run them, but compiling wasm through Craneliftin MIRI is so slow that it doesn't seem worth it at this time. This doesmean that there's a pretty big hole in MIRI's test coverage, but that'sto be expected as we're a JIT compiler after all.To get tests working in MIRI this PR uses a number of strategies:* When platform-specific code is involved there's now `#[cfg(miri)]` for MIRI's version. For example there's a custom-built "mmap" just for MIRI now. Many of these are simple noops, some are `unimplemented!()` as they shouldn't be reached, and some are slightly nontrivial implementations such as mmaps and trap handling (for native-to-native function calls).* Many test modules are simply excluded via `#![cfg(not(miri))]` at the top of the file. This excludes the entire module's worth of tests from MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to ignore tests by default on MIRI. The latter form is used in modules where some tests work and some don't. This means that all future test additions will need to be effectively annotated whether they work in MIRI or not. My hope though is that there's enough precedent in the test suite of what to do to not cause too much burden.* A number of locations are fixed with respect to MIRI's analysis. For example `ComponentInstance`, the component equivalent of `wasmtime_runtime::Instance`, was actually left out from the fix for the CVE by accident. MIRI dutifully highlighted the issues here and I've fixed them locally. Some locations fixed for MIRI are changed to something that looks similar but is subtly different. For example retaining items in a `Store` is now done with a Wasmtime-specific `StoreBox` type. This is because, with MIRI's analyses, moving a `Box` invalidates all pointers derived from this `Box`. We don't want these semantics, so we effectively have a custom `Box` to suit our needs in this regard.* Some default configuration is different under MIRI. For example most linear memories are dynamic with no guards and no space reserved for growth. Settings such as parallel compilation are disabled. These are applied to make MIRI "work by default" in more places ideally. Some tests which perform N iterations of something perform fewer iterations on MIRI to not take quite so long.This PR is not intended to be a one-and-done-we-never-look-at-it-againkind of thing. Instead this is intended to lay the groundwork tocontinuously run MIRI in CI to catch any soundness issues. This feels,to me, overdue given the amount of `unsafe` code inside of Wasmtime. Myhope is that over time we can figure out how to run Wasm in MIRI butthat may take quite some time. Regardless this will be adding nontrivialmaintenance work to contributors to Wasmtime. MIRI will be run on CI formerges, MIRI will have test failures when everything else passes,MIRI's errors will need to be deciphered by those who have probablynever run MIRI before, things like that. Despite all this to me it seemsworth the cost at this time. Just getting this running caught twopossible soundness bugs in the component implementation that could havehad a real-world impact in the future![stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md[tree]: https://perso.crans.org/vanille/treebor/[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question* Update alignment comment List of files: /wasmtime-44.0.1/tests/all/instance.rs

b0939f66 - Remove explicit `S` type parameters (#5275)

Wed, 16 Nov 2022 05:04:26 +0000

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/tests/all/instance.rs

b14551d7 - Refactor configuration for the pooling allocator (#5205)

Fri, 04 Nov 2022 20:06:45 +0000

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/tests/all/instance.rs

3f3afb45 - Remove support for userfaultfd (#4040)

Mon, 18 Apr 2022 17:42:26 +0000

Remove support for userfaultfd (#4040)This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default). List of files: /wasmtime-44.0.1/tests/all/instance.rs

15bb0c69 - Remove the `ModuleLimits` pooling configuration structure (#3837)

Fri, 25 Feb 2022 15:11:51 +0000

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/tests/all/instance.rs

e2b9b543 - Add `paged_memory_initialization` to Config.

Thu, 26 Aug 2021 03:05:48 +0000

Add `paged_memory_initialization` to Config.This commit adds a `paged_memory_initialization` setting to `Config`.The setting controls whether or not an attempt is made to organize datasegments into Wasm pages during compilation.When used in conjunction with the `uffd` feature on Linux, Wasmtime cancompletely skip initializing linear memories and instead initialize any pagesthat are accessed for the first time during Wasm execution. List of files: /wasmtime-44.0.1/tests/all/instance.rs

63a3bbbf - Change VMMemoryDefinition::current_length to `usize` (#3134)

Mon, 02 Aug 2021 18:09:40 +0000

Change VMMemoryDefinition::current_length to `usize` (#3134)* Change VMMemoryDefinition::current_length to `usize` This commit changes the definition of `VMMemoryDefinition::current_length` to `usize` from its previous definition of `u32`. This is a pretty impactful change because it also changes the cranelift semantics of "dynamic" heaps where the bound global value specifier must now match the pointer type for the platform rather than the index type for the heap. The motivation for this change is that the `current_length` field (or bound for the heap) is intended to reflect the current size of the heap. This is bound by `usize` on the host platform rather than `u32` or` u64`. The previous choice of `u32` couldn't represent a 4GB memory because we couldn't put a number representing 4GB into the `current_length` field. By using `usize`, which reflects the host's memory allocation, this should better reflect the size of the heap and allows Wasmtime to support a full 4GB heap for a wasm program (instead of 4GB minus one page). This commit also updates the legalization of the `heap_addr` clif instruction to appropriately cast the address to the platform's pointer type, handling bounds checks along the way. The practical impact for today's targets is that a `uextend` is happening sooner than it happened before, but otherwise there is no intended impact of this change. In the future when 64-bit memories are supported there will likely need to be fancier logic which handles offsets a bit differently (especially in the case of a 64-bit memory on a 32-bit host). The clif `filetest` changes should show the differences in codegen, and the Wasmtime changes are largely removing casts here and there. Closes #3022 * Add tests for memory.size at maximum memory size * Add a dfg helper method List of files: /wasmtime-44.0.1/tests/all/instance.rs

83007b79 - Fix access to VMMemoryDefinition::current_length on big-endian (#3013)

Wed, 23 Jun 2021 16:45:32 +0000

Fix access to VMMemoryDefinition::current_length on big-endian (#3013)The current_length member is defined as "usize" in Rust code, but generated wasm code refers to it as if it were "u32". While this happens to mostly work on little-endian machines (as long as the length is < 4GB), it will always fail on big-endian machines. Fixed by making current_length "u32" in Rust as well, and ensuring the actual memory size is always less than 4GB. List of files: /wasmtime-44.0.1/tests/all/instance.rs

7a1b7cdf - Implement RFC 11: Redesigning Wasmtime's APIs (#2897)

Thu, 03 Jun 2021 14:10:53 +0000

Implement RFC 11: Redesigning Wasmtime's APIs (#2897)Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread. List of files: /wasmtime-44.0.1/tests/all/instance.rs

37bb7af4 - Fix incorrect range in `ininitialize_instance`.

Fri, 02 Apr 2021 23:12:19 +0000

Fix incorrect range in `ininitialize_instance`.This commit fixes a bug where the wrong destination range was used when copyingdata from the module's memory initialization upon instance initialization.This affects the on-demand allocator only when using the `uffd` feature onLinux and when the Wasm page being initialized is not the last in the module'sinitial pages.Fixes #2784. List of files: /wasmtime-44.0.1/tests/all/instance.rs

15c68f2c - Disconnects `Store` state fields from `Compiler` (#1761)

Tue, 02 Jun 2020 18:44:39 +0000

Disconnects `Store` state fields from `Compiler` (#1761)* Moves CodeMemory, VMInterrupts and SignatureRegistry from Compiler * CompiledModule holds CodeMemory and GdbJitImageRegistration * Store keeps track of its JIT code * Makes "jit_int.rs" stuff Send+Sync * Adds the threads example. List of files: /wasmtime-44.0.1/tests/all/instance.rs

4c82da44 - Move most wasmtime tests into one test suite (#1544)

Fri, 17 Apr 2020 22:22:12 +0000

Move most wasmtime tests into one test suite (#1544)* Move most wasmtime tests into one test suite This commit moves most wasmtime tests into a single test suite which gets compiled into one executable instead of having lots of test executables. The goal here is to reduce disk space on CI, and this should be achieved by having fewer executables which means fewer copies of `libwasmtime.rlib` linked across binaries on the system. More importantly though this means that DWARF debug information should only be in one executable rather than duplicated across many. * Share more build caches Globally set `RUSTFLAGS` to `-Dwarnings` instead of individually so all build steps share the same value. * Allow some dead code in cranelift-codegen Prevents having to fix all warnings for all possible feature combinations, only the main ones which come up. * Update some debug file paths List of files: /wasmtime-44.0.1/tests/all/instance.rs