Stream: git-wasmtime

Topic: wasmtime / PR #11460 Make memory growth an async function

Wasmtime GitHub notifications bot (Aug 19 2025 at 19:14):

alexcrichton requested dicej for a review on PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 19:14):

alexcrichton opened PR #11460 from alexcrichton:memory-growth-async to bytecodealliance:main:

This is an analog of https://github.com/bytecodealliance/wasmtime/pull/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 https://github.com/bytecodealliance/wasmtime/pull/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.

Wasmtime GitHub notifications bot (Aug 19 2025 at 19:14):

alexcrichton requested wasmtime-core-reviewers for a review on PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 19:14):

alexcrichton commented on PR #11460:

Note that the first commit here is from https://github.com/bytecodealliance/wasmtime/pull/11459

Wasmtime GitHub notifications bot (Aug 19 2025 at 19:16):

alexcrichton updated PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:36):

fitzgen commented on PR #11460:

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.

Seems like we should call the async limiter of the store that is doing the growth, that way an embedder could still guarantee that all growth is limited from a holistic system point of view, even if one particular store's limiter doesn't handle all the grow calls.

Mind filing a follow up issue for this?

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:40):

alexcrichton commented on PR #11460:

That's theoretically possible yeah but it's already preexisting that the resource limiter isn't used when a SharedMemory is created through the embedder API. There's also still the issue that the rwlock write guard can't be held across an await point which would be a much more invasive change.

I've added a note to https://github.com/bytecodealliance/wasmtime/issues/4245 to accompany similar issues in https://github.com/bytecodealliance/wasmtime/issues/4240 and https://github.com/bytecodealliance/wasmtime/issues/4244

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:42):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:42):

fitzgen created PR review comment:

Mind adding a safety comment while you're here?

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:53):

alexcrichton updated PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 20:53):

alexcrichton has enabled auto merge for PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 21:14):

alexcrichton has disabled auto merge for PR #11460.

Wasmtime GitHub notifications bot (Aug 19 2025 at 21:27):

alexcrichton merged PR #11460.

Last updated: Dec 06 2025 at 07:03 UTC