History log of /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/malloc.rs (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...