fitzgen opened PR #14785 from fitzgen:component-pre-load to bytecodealliance:main:
This required the ability to wrap a live instance into a
wasmtime::component::Linkeras well.<!--
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 review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen requested dicej for a review on PR #14785.
fitzgen requested wasmtime-core-reviewers for a review on PR #14785.
github-actions[bot] added the label wasmtime:api on PR #14785.
fitzgen updated PR #14785.
fitzgen updated PR #14785.
:memo: alexcrichton submitted PR review:
Do you have an immediate use case for this at the moment, and if so could it use
wasm-tools composeorwacin the meantime?I'm hesitant myself to start committing to something here becuase there's a lot that's possible in this space and I'm not sure that this is the best approach. Some thoughts I'd have are:
- Technically
--preloadshould be able to work for core wasm modules loaded into a component, that'd satisfy a component importing a core module for example.Valis so horrendously slow that I'd rather not feature it so prominently within the implementation of an option that I suspect everyone expects to be fast.- Instead of using
Valour thinking historically has been that something performs a composition and Wasmtime sees the composition, so for examplewasmtime --preloadcould compose on-the-fly like it does with unsafe builtins or perhaps something similar to that.- Overall repurposing
--preloadas-is from core modules may not be the best design here. In theory this could support behavior like-Lon linkers where the idea is you can pointwasmtimeto various directories to automatically find and load*.wasms as appropriate.Basically I'm not confident that we should take
--preloadas-is and support it within the CLI, and I'm also not confident in the implementation usingVal. That's what leads me to ask if a composition works for your use case if you have one. Otherwise though I think it's fine to work through these questions/ideas, but I'm not sure if that's what you were expecting to do here.
:thumbs_up: dicej submitted PR review:
LGTM, thanks!
It occurred to me that we could precalculate the parameters which have resource borrows to drop based on the types rather than visit them all at runtime, but I suppose we're not trying to optimize this given that composition remains the fast path.
Oops, my review crossed with Alex's; he makes some good points about e.g. using WAC just-in-time.
fitzgen commented on PR #14785:
My immediate goal is to be able to easily run+profile sightglass benchmarks without needing to stub out the
bench.start/bench.endimports. I could usewacor whatever, but that is a bit more annoying and less it-just-works-out-of-the-box compared to core wasm, but I guess that is fine as a temporary workaround.
:cross_mark: fitzgen closed without merge PR #14785.
Last updated: Oct 31 2026 at 23:03 UTC