alexcrichton opened PR #11442 from alexcrichton:really-start-the-async-journey to bytecodealliance:main:
Upon further refactoring and thinking about #11430 I've realized that we might be able to sidestep
T: Sendon the store entirely which would be quite the boon if it can be pulled off. The realization I had is that the main reason for this was&mut dyn VMStoreon the stack, but that itself is actually a bug in Wasmtime (#11178) and shouldn't be done. The functions which have this on the stack should actually ONLY have the resource limiter, if configured. This means that while theResourceLimiter{,Async}traits need aSendsupertrait that's relatively easy to add without much impact. My hunch is that plumbing this through to the end will enable all the benefits of #11430 without requiring addingT: Sendto the store.This commit starts out on this journey by making table growth a true
async fn. A new internal type is added to represent a store's limiter which is plumbed to growth functions. This represents a hierarchy of borrows that look like:
StoreInner<T>
StoreResourceLimiter<'_>StoreOpaque
Pin<&mut Instance>
&mut vm::TableThis notably, safely, allows operating on
vm::Tablewith aStoreResourceLimiterat the same time. This is exactly what's needed and prevents needing to have&mut dyn VMStore, the previous argument, on the stack.This refactoring cleans up
unsafeblocks in table growth right now which manually uses raw pointers to work around the borrow checker. No more now!I'll note as well that this is just an incremental step. What I plan on doing next is handling other locations like memory growth, memory allocation, and table allocation. Each of those will require further refactorings to ensure that things like GC are correctly accounted for so they're going to be split into separate PRs. Functionally though this PR should have no impact other than a fiber is no longer required for
Table::grow_async.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested pchickey for a review on PR #11442.
alexcrichton requested wasmtime-core-reviewers for a review on PR #11442.
alexcrichton updated PR #11442.
pchickey submitted PR review.
alexcrichton merged PR #11442.
Last updated: Dec 06 2025 at 07:03 UTC