Adjust behavior of 4gb memories with custom page sizes (#12884)

* Adjust behavior of 4gb memories with custom page sizes

This commit adjust what happens when a linear memory grows up to 4gb
large w

Adjust behavior of 4gb memories with custom page sizes (#12884)

* Adjust behavior of 4gb memories with custom page sizes

This commit adjust what happens when a linear memory grows up to 4gb
large when custom page sizes are used. This is an open question in the
upstream proposal at WebAssembly/custom-page-sizes#45 but without any
special handling a return value of -1 is ambiguous if it succeeded or
failed. For now eagerly trap memory operations reaching these conditions
while the upstream specification question is resolved.

* Fix CI

* Debug CI failure

prtest:full

* Fix 32-bit platforms

show more ...

Handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function (#12855)

* Use `try_new` for `Box<dyn RuntimeLinearMemory>` in `DefaultMemoryCreator`

* Use `TryPrim

Handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function (#12855)

* Use `try_new` for `Box<dyn RuntimeLinearMemory>` in `DefaultMemoryCreator`

* Use `TryPrimaryMap` for `host_globals` in `Store`

* Add `Func::try_wrap` and use `try_new` for `Box<HostFunc>`

Add `Func::try_wrap` as a fallible version of `Func::wrap` that returns an error
on out-of-memory instead of panicking. `Func::wrap` now delegates to `try_wrap`.

Also use `try_new::<Box<_>>` instead of `Box::new` for `HostFunc`.

* Use `bumpalo`'s `try_alloc` for `FuncRefs`

* Use `try_new` for `Arc<Module>` in "trampoline" code

* Test that we handle OOM in `{Func,Memory,Table,Global}::new` and when calling an instance's exported function

* cargo fmt

show more ...

"Downgrade" threads support to tier 2, disable fuzzing (#12036)

* "Downgrade" threads support to tier 2, disable fuzzing

This commit is borne out of a fuzz bug that was opened recently. The
fuzz bu

"Downgrade" threads support to tier 2, disable fuzzing (#12036)

* "Downgrade" threads support to tier 2, disable fuzzing

This commit is borne out of a fuzz bug that was opened recently. The
fuzz bug specifically has to do with fallout from #12022, specifically
`SharedMemory` being used to allocated instead of `Memory`. In this
situation the resource limiter is no longer consulted meaning that
shared memories bypass this and aren't caught by OOM checks. This is
currently by design because `SharedMemory` instances don't know which
resource limiter to hook into per-store.

More generally though the implementation of wasm threads, while workable
in Wasmtime, has a number of known relatively large deficiencies. These
were not resolved prior to ungating the wasm proposal (that's on me) but
nevertheless the quality of implementation is not quite up to "tier 1
par" with the rest of what Wasmtime offers. Given this the threads
proposal is now downgraded to tier 2. To help minimize the impact of
this the wasm proposal is left enabled-by-default, but creation of a
`SharedMemory` in the Rust API requires opting-in via a new
`Config::shared_memory` method.

This commit shuffles around some documentation of wasm proposals to
split it into tier 1/2/3 instead of on/off-by-default and then adds a
column for whether the proposal is on-by-default.

* clangformat

* Fix tests

* Add tests for failed creation

Fix an issue where defined shared memories weren't gated

* Sync disabled threads stub

* Fix another test

prtest:full

* Fix fuzzing tests

* Fix dwarf tests

show more ...

Fix off-by-one bounds check for atomic operations (#11977)

They're allowed to happen if the final address is the memory's length,
as opposed to being one-less-than-the-memory's length.

Closes #11975

Refactor resetting memory on `MemoryImageSlot` drop (#11510)

* Refactor resetting memory on `MemoryImageSlot` drop

This commit refactors the behavior of dropping a `MemoryImageSlot` to no
longer ma

Refactor resetting memory on `MemoryImageSlot` drop (#11510)

* Refactor resetting memory on `MemoryImageSlot` drop

This commit refactors the behavior of dropping a `MemoryImageSlot` to no
longer map anonymous memory into the slot. This behavior was implemented
previously because if a `MemoryImageSlot` is dropped then the state of
the slot is unknown and to prevent any sort of data leakage a reset is
performed.

This reset operation, however, is fallible in that it calls `mmap`.
Calls to `mmap` can fail due to `ENOMEM`, for example, if the process
has reached its VMA limit. This means that if a process is in a near-OOM
condition then failing to allocate a memory image could panic the
process due to the `unwrap()` in the destructor of `MemoryImageSlot`.
The purpose of this commit is to avoid this `unwrap()` and instead move
the reset behavior to a location where an error can be propagated.

This commit removes the clear-on-drop behavior of `MemoryImageSlot`
slot. This was already disabled everywhere except the pooling allocator.
The pooling allocator now maintains an extra bit of state-per-slot where
instead of storing `Option<MemoryImageSlot>` it now stores effectively
one other variant of "unknown". On reuse of an "unknown" slot the memory
is reset back to an anonymous mapping and this is all done in a context
where an error can be propagated.

Two tests are added in this commit to confirm all of this behavior:

* The first test is a new test that passes both before and after this
commit which performs a failed allocation of a memory slot. A
successful allocation is then made to ensure that the previous image
is not present and zero memory is present. This test fails before the
commit if the clear-on-drop behavior is removed, and it fails with this
commit if the clear-on-reusing-unknown behavior is removed.
Effectively this test ensures that the clear-on-unknown-state logic is
present.

* The second test is a new test that panicked before this commit and
passes afterwards. This second test exhausts all VMAs in the current
process, or at least most of them, and then tries to allocate some
instances with an image. Instance allocation will eventually fail and
cause the erroneous path to get executed. This previously unwrapped a
`ENOMEM` failure, and now it can be handled gracefully by the
embedder.

* Skip the new test on QEMU, it fails on CI

* Only run test on Linux

show more ...

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `Store

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `StoreOpaque::allocate_instance` is now an `async fn`.
This function does not actually use the `async`-ness just yet so it's a
noop from that point of view, but this propagates outwards to enough
locations that I wanted to split this off to make future changes more
digestable.

Notably some creation functions here such as making an `Instance`,
`Table`, or `Memory` are refactored internally to use this new `async`
function. Annotations of `assert_ready` or `one_poll` are used as
appropriate as well.

For reference this commit was benchmarked with our `instantiation.rs`
benchmark in the pooling allocator and shows no changes relative to the
original baseline from before-`async`-PRs.

* Make table/memory creation `async` functions

This commit is a large-ish refactor which is made possible by the many
previous refactorings to internals w.r.t. async-in-Wasmtime. The end
goal of this change is that table and memory allocation are both `async`
functions. Achieving this, however, required some refactoring to enable
it to work:

* To work with `Send` neither function can close over `dyn VMStore`.
This required changing their `Option<&mut dyn VMStore>` arugment to
`Option<&mut StoreResourceLimiter<'_>>`
* Somehow a `StoreResourceLimiter` needed to be acquired from an
`InstanceAllocationRequest`. Previously the store was stored here as
an unsafe raw pointer, but I've refactored this now so
`InstanceAllocationRequest` directly stores `&StoreOpaque` and
`Option<&mut StoreResourceLimiter>` meaning it's trivial to acquire
them. This additionally means no more `unsafe` access of the store
during instance allocation (yay!).
* Now-redundant fields of `InstanceAllocationRequest` were removed since
they can be safely inferred from `&StoreOpaque`. For example passing
around `&Tunables` is now all gone.
* Methods upwards from table/memory allocation to the
`InstanceAllocator` trait needed to be made `async`. This includes new
`#[async_trait]` methods for example.
* `StoreOpaque::ensure_gc_store` is now an `async` function. This
internally carries a new `unsafe` block carried over from before with
the raw point passed around in `InstanceAllocationRequest`. A future
PR will delete this `unsafe` block, it's just temporary.

I attempted a few times to split this PR up into separate commits but
everything is relatively intertwined here so this is the smallest
"atomic" unit I could manage to land these changes and refactorings.

* Shuffle `async-trait` dep

* Fix configured build

show more ...

Make memory growth an async function (#11460)

* Make memory growth an `async` function

This is an analog of #11442 but for memories. This had a little more
impact due to memories being hooked into

Make memory growth an async function (#11460)

* Make memory growth an `async` function

This is an analog of #11442 but for memories. This had a little more
impact due to memories being hooked into GC operations. Further
refactoring of GC operations to make them safer/more-async is deferred
to a future PR and for now it's "no worse than before". This is another
step towards #11430 and enables removing a longstanding `unsafe` block
in `runtime/memory.rs` which previously could not be removed.

One semantic change from this is that growth of a shared memory no
longer uses an async limiter. This is done to keep growth of a shared
memory consistent with creation of a shared memory where no limits are
applied. This is due to the cross-store nature of shared memories which
means that we can't tie growth to any one particular store. This
additionally fixes an issue where an rwlock write guard was otherwise
held across a `.await` point which creates a non-`Send` future, closing
a possible soundness hole in Wasmtime.

* Fix threads-disabled build

* Review comments

show more ...

Gut `vm::Export` to mostly be `crate::Extern` (#11229)

* Remove `Table::from_wasmtime_table`

This commit removes the unsafe function `Table::from_wasmtime_table`.
This goes a bit further and remove

Gut `vm::Export` to mostly be `crate::Extern` (#11229)

* Remove `Table::from_wasmtime_table`

This commit removes the unsafe function `Table::from_wasmtime_table`.
This goes a bit further and removes `ExportTable` entirely as well which
means that table lookup on a `vm::Instance` directly returns a
`wasmtime::Table` without any need to translate back-and-forth.

* Remove `Tag::from_wasmtime_tag`

Like the previous commit, but for tags.

* Remove `Global::from_wasmtime_global`

Like the previous commit, but for globals.

* Remove `Memory::from_wasmtime_memory`

Like the previous commit, but for memories.

* Remove `Func::from_wasmtime_function`

Like previous commits, but for functions.

* Fix lints

* Fill out missing safety comment

* Review comments

show more ...

Cache the `VMMemoryDefinition` in the DRC collector (#11167)

Removes about 1/8th of the time spent in the test case in
https://github.com/bytecodealliance/wasmtime/issues/11141 for me locally.

Fixe

Cache the `VMMemoryDefinition` in the DRC collector (#11167)

Removes about 1/8th of the time spent in the test case in
https://github.com/bytecodealliance/wasmtime/issues/11141 for me locally.

Fixes https://github.com/bytecodealliance/wasmtime/issues/11163

show more ...

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 ...

Make a couple `vm::Memory` methods take `&self` instead of `&mut self` (#10543)

The `&mut self` was not necessary and also did not provide any help with using
the resulting `VMMemoryDefinition`s and

Make a couple `vm::Memory` methods take `&self` instead of `&mut self` (#10543)

The `&mut self` was not necessary and also did not provide any help with using
the resulting `VMMemoryDefinition`s and their raw pointers, so just make these
methods take `&self`.

show more ...

Enable warnings if `pooling-allocator` is disabled (#10142)

* Enable warnings if `pooling-allocator` is disabled

Continuation of work in #10131

* Fix windows build

Enable warnings if `threads` is disabled (#10136)

Continuation of work in #10131

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today th

Provenance preparation for Pulley (#10043)

* Provenance preparation for Pulley

This commit is an internal refactoring of Wasmtime's runtime to prepare
to execute Pulley in MIRI. Currently today this is not possible because
Pulley does not properly respect either strict or permissive provenance
models. The goal of this refactoring is to enable fixing this in a
future commit that doesn't touch everything in the codebase. Instead
everything is touched here in this commit.

The basic problem with Pulley is that it is incompatible with the strict
provenance model of Rust which means that we'll be using "exposed
provenance" APIs to satisfy Rust's soundness requirements. In this model
we must explicitly call `ptr.expose_provenance()` on any pointers
which are exposed to compiled code. Arguably we should also be already
doing this for natively-compiled code but I am not certain about how
strictly this is required.

Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.
It also turns out, though, that we share quite a few pointers in quite a
few places with compiled code. This creates a bit of a problem! The
solution settled on in this commit looks like:

* A new marker trait, `VmSafe`, is introduced. This trait is used to
represent "safe to share with compiled code" types and enumerates some
properties such as defined ABIs, primitives wrappers match primitive
ABIs, and notably "does not contain a pointer".

* A new type, `VmPtr<T>`, is added to represent pointers shared with
compiled code. Internally for now this is just `SendSyncPtr<T>` but in
the future it will be `usize`. By using `SendSyncPtr<T>` it shouldn't
actually really change anything today other than requiring a lot of
refactoring to get the types to line up.

* The core `vmctx_plus_offset*` methods are updated to require
`T: VmSafe`. Previously they allowed any `T` which is relatively
dangerous to store any possible Rust type in Cranelift-accessible
areas.

These three fundamental changes were introduced in this commit. All
further changes were refactoring necessary to get everything working
after these changes. For example many types in `vmcontext.rs`, such as
`VMFuncRef`, have changed to using `VmPtr<T>` instead of `NonNull<T>` or
`*mut T`. This is a pretty expansive change which resulted in touching a
lot of places.

One premise of `VmPtr<T>` is that it's non-null. This was an
additional refactoring that updated a lot of places where previously
`*mut T` was used and now either `VmPtr<T>` or `NonNull<T>` is used.

In the end the intention is that `VmPtr<T>` is used whenever pointers
are store in memory that can be accessed from Cranelift. When operating
inside of the runtime `NonNull<T>` or `SendSyncPtr<T>` is preferred
instead.

As a final note, no provenance changes have actually happened yet. For
example this doesn't fix Pulley in MIRI. What it does enable, though, is
that the future commit to fix Pulley in MIRI will be much smaller with
this having already landed.

* Run the full test suite in PR CI

prtest:full

* Minor CI issues

* Fix no_std build

* Fix miri build

* Don't use `VmPtr` in FFI function signatures

Use `NonNull` or `*mut u8` as appropriate for function signatures
instead. It shouldn't be required to use `VmPtr` during the handoff to
compiled code as we've already annotated the pointer going out.

* Fix rebase conflict

* Review comments

show more ...

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the previously added `signals-based-traps` feature in
favor of auto-detecting whether it's there or not. The `build.rs`
script for the `wasmtime` crate will now detect the target platform and
auto-enable this feature as necessary.

The `signals-based-traps` cargo feature is removed and split into two
custom `#[cfg]` directives that the build script sets:

* `has_virtual_memory` - this is used to gate mmap implementations for
example. This is enabled on `unix || windows` and will be off for
`no_std` targets for example. This is split out of
"signals-based-traps" to better handle platforms like iOS which have
virtual memory but don't execute native code (removing the need for
native signals).

* `has_native_signals` - gates signal handlers on Unix for example. This
is disabled on MIRI but otherwise enabled for `unix || windows`. This
is intended to in the future get disabled for iOS by default for
example since it's not necessary when using Pulley. This is
additionally off-by-default for `no_std` platforms.

Two new crate features were added for `no_std` or "custom" platforms to
opt-in to the `wasmtime-platform.h` C APIs for implementing virtual
memory and signals. These are used in the `min-platform` embedding example.

This commit additionally updates some various documentation here and
there to be more up-to-date.

* Update CI configuration

* Fix compile warnings

* Fix test on miri

* Fix more tests on miri

* Fix some warnings

* Another round of miri/CI attempts/fixes

prtest:full

show more ...

pulley: Ungate memory64 feature (#9780)

* pulley: Ungate memory64 feature

This commit is similar to #9779 in that it's removing a proposal from
the "known list of panicking features" for Pulley to

pulley: Ungate memory64 feature (#9780)

* pulley: Ungate memory64 feature

This commit is similar to #9779 in that it's removing a proposal from
the "known list of panicking features" for Pulley to allow more tests to
run on Pulley. This then fills out a few miscellaneous instructions to
get a full suite of tests passing in Pulley related to memory64 and
other instructions.

prtest:full

* Add notes about spectre speculation

show more ...

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 ...

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

This commit extends our CI for i686 and armv7 to test the Pulley
backend, namely the full `*.wast` test suite as well as the `wasmtime`
crate itself

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

This commit extends our CI for i686 and armv7 to test the Pulley
backend, namely the full `*.wast` test suite as well as the `wasmtime`
crate itself. Note that many `*.wast` tests are still expected to fail
at this time.

This involved fixing a number of 32-vs-64 bit issues throughout the test
suite in various location in this commit.

show more ...

move most of runtime/vm/cow.rs over to aligned byte counts (#9652)

* move most of runtime/vm/cow.rs over to aligned byte counts

As part of attempting to move some of these operations over to Mmap i

move most of runtime/vm/cow.rs over to aligned byte counts (#9652)

* move most of runtime/vm/cow.rs over to aligned byte counts

As part of attempting to move some of these operations over to Mmap instances,
it is nice to have type-level checking for aligned sizes. In upcoming PRs, APIs
like `map_at` will be switched to using `Mmap` instances with aligned counts.

There are a couple of spots where I have questions -- will flag them in review
comments.

* address review comments, incl workaround for #9660

show more ...

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 ...

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 ...

Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)

* Refactor internals of `vm::Memory`

Instead of storing just a trait object store instead an `enum` betwee

Refactor the internals of `vm::Memory` to simplify the `RuntimeLinearMemory` trait (#9577)

* Refactor internals of `vm::Memory`

Instead of storing just a trait object store instead an `enum` between
"local" memory and shared memory. This helps remove redundant trait
impls on shared memories, removes the need for `dyn Any`, and removes
the possibility of wrapping a shared memory as a shared memory. This is
additionally intended to make it a bit easier to see what's nested where
and reduce some layers of indirection.

* Start implementing a `LocalMemory` abstraction

This is intended to be a non-shared implementation of a linear memory
with various bits and pieces tracking state. The end goal is to simplify
the `RuntimeLinearMemory` trait to its bare bones necessary to
faithfully implement wasm linear memory.

* Move `vmmemory` to `LocalMemory`

* Move CoW/max limits into `LocalMemory`

Further simplify `RuntimeLinearMemory` by moving these responsibilities
up a layer into the `LocalMemory` structure.

* Simplify `memory_may_move` handling in `LocalMemory`

No need to plumb it through all the traits any more. Now it's possible
to only have it handled in `LocalMemory` and other pieces don't have to
worry about it.

* Move `wasm_accessible` into `LocalMemory`

Further simplify custom traits and mmap/static memory by moving more
responsibility into `LocalMemory`.

* Improve documentation of memories

* Fix some CI failures

* Handle more CI failures

* More fixes for CI

* Update crates/wasmtime/src/runtime/vm/memory.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Don't use `MemoryStyle` in `MmapMemory` (#9574)

This commit removes the use fo `MemoryStyle` for determining the size of
the allocation of a `MmapMemory`. This should semanatically be the same
as be

Don't use `MemoryStyle` in `MmapMemory` (#9574)

This commit removes the use fo `MemoryStyle` for determining the size of
the allocation of a `MmapMemory`. This should semanatically be the same
as before but it's hoped that the new version is clearer to understand
as it doesn't require going through the `MemoryStyle` abstraction to
understand how tunables interact with linear memory. The semantics for
the allocation of linear memory are:

reservation = tunables.memory_reservation
growth = tunables.memory_reservation_for_growth
if maximum <= reservation {
growth = 0
} else if minimum <= reservation {
// use settings above
} else {
reservation = minimum + growth
}

This means that the initial memory allocation is always
`tunables.memory_reservation` unless that's not large enough to fit the
linear memory. In such a situation the other settings, such as
`memory_reservation_for_growth`, kick in.

The logic of clamping the maximum and/or dealing with static/dynamic are
now all unnecessary and/or tracked elsewhere. For example the clamping
nature of `maximum` now happens implicitly by rejecting growth when
`memory_may_move` is false which should help keep that complexity
localized where necessary rather than conflating multiple settings
together.

show more ...

Don't use `MemoryStyle` for heap base pointer relocations (#9569)

* Don't use `MemoryStyle` for heap base pointer relocations

Instead add a helper method to `Memory` which indicates whether the bas

Don't use `MemoryStyle` for heap base pointer relocations (#9569)

* Don't use `MemoryStyle` for heap base pointer relocations

Instead add a helper method to `Memory` which indicates whether the base
pointer of memory can move. Use this and plumb the result around to the
various locations that require it. This improves the `readonly`
application of the base pointer in Cranelift by having the optimization
kick in in more scenarios. It additionally fixes combining shared linear
memories with 64-bit addressing or a page size of 1 by adding a runtime
check before relocation of a linear memory that it's allowed to do so.

A few codegen tests are added to ensure that `readonly` is applied where
it wasn't previously and additionally a new `*.wast` test was added with
the cross product of various features of linear memories and some basic
tests to ensure that the memories all work as expected.

This refactoring fixes two preexisting issues about `shared` memories
requiring a "static" memory style. The restriction is now based on
whether the pointer can relocate or not and that's upheld via the new
trait method added here.

To account for these bug fixes the fuzzers have been updated to allow
mixing the `threads` proposal with `memory64` or `custom-page-sizes`.

Closes #4267
Closes #9523

* Optionally increase the allocation size for dynamic memories

This code will be short-lived due to scheduled future refactorings but
the idea is that when a "dynamic" memory is chosen the minimum size of
the allocation needs to be at least `tunables.memory_reservation` to fit
the constraints of the rest of the system, so be sure to factor that
in.

show more ...

More refactoring to remove `MemoryStyle` (#9543)

* Remove tuple return value of `MemorysStyle::for_memory`

The second option is always `tunables.memory_guard_size`, so propagate
this to the various

More refactoring to remove `MemoryStyle` (#9543)

* Remove tuple return value of `MemorysStyle::for_memory`

The second option is always `tunables.memory_guard_size`, so propagate
this to the various locations reading it.

* Remove `offset_guard_size` from compiler `Heap` structs

Push reading `Tunables` down further into where it's needed instead of
having duplicate storage per-heap.

* Plumb wasm memory types further down in Winch

This commit plumbs `wasmtime_environ::Memory` further down the stack in
Winch to where heaps are processed. This avoids an extra layer of
indirection through a `Heap` type which peels apart a `Memory` to pick
out a few fields. In the future this'll be used with more helpers on
`Memory` to simplify the static/dynamic memory cases.

* Plumb memory type further down in Cranelift

This commit removes the `HeapStyle` structure from Cranelift and instead
plumbs the `wasmtime_environ::Memory` type further down the stack
through in `HeapData` (same as Winch before this commit). This removes
redundant fields in `MemoryType` and continues to push down the
`MemoryStyle` structure even further.

This commit additionally and unconditionally defines a `GlobalValue` for
the heap limit of memory. This is unused most of the time for 32-bit
wasm and is conditionally used depending on how bounds checks are
generated. This is a small amount of bloat to each function since
previously functions that didn't need this `GlobalValue` elided it. A
future refactoring, however, will make it a bit more clear how this is
used even for "static" memories.

* Update test expectations

show more ...