|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6 |
|
| #
b8f882d1 |
| 19-Feb-2026 |
Demilade Sonuga <[email protected]> |
Add support for fine-grained operator costs (#11572) (#12541)
Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring per-operator fuel costs via `Config::operator_cost`. Previously
Add support for fine-grained operator costs (#11572) (#12541)
Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring per-operator fuel costs via `Config::operator_cost`. Previously, operator costs were hardcoded inline in both Cranelift and Winch code generation. Now the cost logic is centralized in `wasmtime-environ` and referenced from both backends via `tunables.operator_cost.cost(op)`.
`OperatorCostStrategy` is an enum with two variants: - `Default`: reproduces the original hardcoded behavior (nop/drop/control flow cost 0, everything else costs 1). - `Table(Box<OperatorCost>)`: a per-operator cost table generated via `wasmparser::for_each_operator!`.
Because `OperatorCostStrategy::Table` contains a `Box`, the type has a destructor. This makes `Tunables` non-trivially droppable, which prevents using the `..Tunables::default_miri()` functional update syntax in const functions (E0493). To work around this, `default_miri`, `default_u32`, and `default_u64` are changed to non-const fns. None of these are called in const contexts, except in tests.
show more ...
|
|
Revision tags: v41.0.3, v41.0.2 |
|
| #
c656ed3b |
| 29-Jan-2026 |
Alex Crichton <[email protected]> |
Add context to malloc-based-memory error messages (#12468)
Add in byte counts with more rationale on where the numbers are coming from.
Closes #12445
|
|
Revision tags: v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2 |
|
| #
046a51ca |
| 27-Jun-2025 |
Nick Fitzgerald <[email protected]> |
Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory` (#11148)
* Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory`
Getting the base pointer from the underlying `dyn RuntimeLinearM
Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory` (#11148)
* Avoid cloning and dropping `Arc`s in `LocalMemory::vmmemory`
Getting the base pointer from the underlying `dyn RuntimeLinearMemory` involved getting a `MemoryBase` which is potentially an `MmapOffset` which itself contains an `Arc<Mmap>`, and we would then call `base.as_non_null()` to turn this into a raw pointer, and then we would drop the `MemoryBase` which ultimately drops the `Arc<Mmap>`. So that's an `Arc` clone and drop just to get a `VMMemoryDefinition`, which is just a pointer and a length, essentially a slice of the linear memory. And, among other places, we call `LocalMemory::vmmemory` to get the GC heap's memory base and bound every time we access a GC object from Rust (for example, during collections).
Altogether, this removes another 30% of runtime from the testcase in https://github.com/bytecodealliance/wasmtime/issues/11141
* Construct `VMMemoryDefinition`s in the `RuntimeLinearMemory` implementation
Instead of in `LocalMemory` via calling various `RuntimeLinearMemory` methods, as `LocalMemory` has a `dyn RuntimeLinearMemory` object so those calls are all indirect.
show more ...
|
|
Revision tags: v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0 |
|
| #
90ac295e |
| 19-May-2025 |
Alex Crichton <[email protected]> |
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this switch. This commit moves Wasmtim
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this switch. This commit moves Wasmtime to the 2024 Edition to keep up-to-date with Rust idioms and access many of the edition features exclusive to the 2024 edition.
prtest:full
* Reformat with the 2024 edition
show more ...
|
|
Revision tags: v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0 |
|
| #
d5ee2a04 |
| 06-Dec-2024 |
Rain <[email protected]> |
Move MemoryImageSource::map_at to mmap module (#9687)
* Simplify mmap interface slightly
Return a single `SendSyncPtr` -- the platform-independent context converts to the various raw pointer types
Move MemoryImageSource::map_at to mmap module (#9687)
* Simplify mmap interface slightly
Return a single `SendSyncPtr` -- the platform-independent context converts to the various raw pointer types as desired. This simplifies upcoming work where I wanted to return a `SendSyncPtr`.
* Move MemoryImageSource::map_at to mmap module
This is part of the work to centralize memory management into the `mmap` module. This commit introduces a few structures which aid in that process, and starts converting one of the functions (`MemoryImageSource::map_at`) into this module.
The structures introduced are:
* `MemoryBase`: `RuntimeLinearMemory::base_ptr` is now `RuntimeLinearMemory::base`, which returns a `MemoryBase`. This is either a raw pointer or an `MmapOffset` as described below.
* `MmapOffset`: A combination of a reference to an mmap and an offset into it. Logically represents a pointer into a mapped section of memory.
In future work, we'll move more image-mapping code over to `Mmap` instances.
show more ...
|
| #
9034e101 |
| 03-Dec-2024 |
Alex Crichton <[email protected]> |
Rely on `core::error::Error` (#9702)
* Rely on `core::error::Error`
With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is available which means that in `no_std` mode the `Error`
Rely on `core::error::Error` (#9702)
* Rely on `core::error::Error`
With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is available which means that in `no_std` mode the `Error` trait can be used. This has been integrated into `anyhow::Error` already upstream and means that we can remove our own local hacks such as the `Err2Anyhow` trait.
This commit removes the `Err2Anyhow` trait and all usage, going back to idiomatic Rust error propagation and conversion even in the `no_std` world. This should make code more portable by default and remove some weird idioms we had for supporting this.
prtest:full
* Add some trusted vets
* Audit object crate update
* Disable backtraces on CI
show more ...
|
| #
27ce0bab |
| 20-Nov-2024 |
Alex Crichton <[email protected]> |
Improve `MallocMemory` implementation (#9634)
* Optimize memory growth in debug mode which was showing up locally in profiles as being particularly slow. * Fix a bug where the `memory_reservation_
Improve `MallocMemory` implementation (#9634)
* Optimize memory growth in debug mode which was showing up locally in profiles as being particularly slow. * Fix a bug where the `memory_reservation_for_growth` was accidentally initialized instead of leaving it uninitialized as intended.
show more ...
|
| #
34504fed |
| 20-Nov-2024 |
Alex Crichton <[email protected]> |
Move `memory_init_cow` option to `Tunables` (#9632)
This commit moves the configuration option from `Config` to `Tunables` to ensure that the memory allocation backend has access to it and then it's
Move `memory_init_cow` option to `Tunables` (#9632)
This commit moves the configuration option from `Config` to `Tunables` to ensure that the memory allocation backend has access to it and then it's used to specifically avoid choosing a malloc-based memory because CoW isn't compatible with malloc.
show more ...
|
|
Revision tags: v27.0.0 |
|
| #
d3132c9d |
| 19-Nov-2024 |
Alex Crichton <[email protected]> |
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `si
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `signals-based-traps`. This is modeled after the `Config::signals_based_traps` configuration at runtime and can be used to statically disable the use of signal handlers in Wasmtime. This notably reduces the number of platform dependencies that Wasmtime has and provides a mode of avoiding relying on signals altogether.
This introduces a new `MallocMemory` which is a linear memory backed by the system allocator. This new type of memory is enabled when virtual memory guards are disabled and signals-based-traps are disabled. This means that this new type of memory will be candidate for fuzzing for example.
prtest:full
* Fix rebase conflict
* Refactor `MmapVec` documentation and representation
* Remove no-longer-needed `Arc` * Document it may be backed by `Vec<u8>`
show more ...
|