Only create `ConcurrentState` in a `Store` when CM async is enabled #12377

fitzgen · 2026-01-20T22:07:39Z

Creating the default ConcurrentState will create a FuturesUnordered which will allocate. By making this state optional, we can keep making progress on #12069, and put off dealing with FuturesUnordered until when we are ready to try and make CM async code handle OOMs.

crates/wasmtime/src/runtime/store.rs

Creating the default `ConcurrentState` will create a `FuturesUnordered` which will allocate. By making this state optional, we can keep making progress on bytecodealliance#12069, and put off dealing with `FuturesUnordered` until when we are ready to try and make CM async code handle OOMs.

fitzgen · 2026-01-21T23:31:31Z

So I got things working, but I had to effectively turn cfg(feature = "component-model-async") from being a static, compile-time only feature to also being a dynamic, run-time feature. @alexcrichton you probably have opinions here.

github-actions · 2026-01-22T02:31:22Z

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

If you added a new Config method, you wrote extensive documentation for
it.

Details

Our documentation should be of the following form:

Short, simple summary sentence.

More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.

Is this method fallible? If so, when can it return an error?

Can this method panic? If so, when does it panic?

# Example

Optional example here.

If you added a new Config method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.

Details

For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.

Often, all that is required of you is to ensure that there is a knob for this
configuration option in wasmtime_fuzzing::Config (or one
of its nested structs).

Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See our docs on fuzzing for more details.
If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.

Details

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

dicej

LGTM, thanks.

Regarding the WAST test failures: now that the component model combines resource, task, thread, future, stream, and error-context handles all into a single table, tests involving those handles can be sensitive to whether or not e.g. a thread handle has been implicitly allocated as part of a call. For example, the first resource handle created by a guest will have a value of 1 if a thread handle was not allocated (i.e. because CM concurrency is disabled), but it will have a value of 2 if a thread handle was allocated. Also, Wasmtime makes the distinction between "not a valid handle at all" and "a valid handle, but not of the expected kind (e.g. a thread handle being used as a resource handle)".

I made this update as part of #12379; I suspect we'll need to do the same here. In some cases, that might mean explicitly enabling CM async for a given WAST (assuming it's been written with the assumption that a thread handle is allocated for each guest call). In other cases, it might mean changing the expected trap message and/or expected handle values. I can tackle that, if you'd like.

fitzgen · 2026-01-22T16:45:45Z

Thanks! Flagging the two offending wast tests as requiring CM async was straightforward and resolved the issues

alexcrichton · 2026-01-22T19:23:17Z

src/commands/serve.rs

            .common
            .config(use_pooling_allocator_by_default().unwrap_or(None))?;
        config.wasm_component_model(true);
+        config.wasm_component_model_async(true);


How come this was enabled? For debugging, or intentional?

As an unstable feature this is something I'd ideally like to keep turned off until component-model-async is ready

wasmtime serve and wasi-http unconditionally use the concurrency machinery today. We don't have a separate switch for the internal concurrency machinery vs the Wasm-facing component model async feature. Probably we need something like GC_TYPES, I suppose.

Hm ok yeah I think we'll definitely want something disconnected from wasm feature validation for this. I'll work on that.

This commit is an extension/refactor of bytecodealliance#12377 and bytecodealliance#12379. Notably this decouples the runtime behavior of Wasmtime from enabled/disabled WebAssembly proposals. This enables the `wasmtime serve` subcommand, for example, to continue to disallow component-model-async by default but continue to use `*_concurrent` under the hood. Specifically a new `Config::concurrency_support` knob is added. This is plumbed directly through to `Tunables` and takes over the preexisting `component_model_concurrency` field. This field configures whether tasks/etc are enabled at runtime for component-y things. The default value of this configuration option is the same as `cfg!(feature = "component-model-async")`, and this field is required if component-model-async wasm proposals are enabled. It's intended that eventually this'll affect on-by-default wasm features in Wasmtime depending if the support is compiled in. This results in a subtle shift in behavior where component-model-async concurrency is used by default now because the feature is turned on by default, even though the wasm features are off-by-default. This required adjusting a few indices expected in runtime tests due to tasks/threads being allocated in index spaces. Finally, this additionally denies access at runtime to `Linker::*_concurrent` when concurrent support is disabled as otherwise the various runtime data structures won't be initialized and panics will happen. Closes bytecodealliance#12393

* Document panics from using CM async machinery when CM async is not enabled * Refactor how concurrency support is enabled in a `Store` This commit is an extension/refactor of #12377 and #12379. Notably this decouples the runtime behavior of Wasmtime from enabled/disabled WebAssembly proposals. This enables the `wasmtime serve` subcommand, for example, to continue to disallow component-model-async by default but continue to use `*_concurrent` under the hood. Specifically a new `Config::concurrency_support` knob is added. This is plumbed directly through to `Tunables` and takes over the preexisting `component_model_concurrency` field. This field configures whether tasks/etc are enabled at runtime for component-y things. The default value of this configuration option is the same as `cfg!(feature = "component-model-async")`, and this field is required if component-model-async wasm proposals are enabled. It's intended that eventually this'll affect on-by-default wasm features in Wasmtime depending if the support is compiled in. This results in a subtle shift in behavior where component-model-async concurrency is used by default now because the feature is turned on by default, even though the wasm features are off-by-default. This required adjusting a few indices expected in runtime tests due to tasks/threads being allocated in index spaces. Finally, this additionally denies access at runtime to `Linker::*_concurrent` when concurrent support is disabled as otherwise the various runtime data structures won't be initialized and panics will happen. Closes #12393 * Add a `-Wconcurrency-support` CLI flag Used to update disas tests to show that, when disabled, old codegen quality is preserved * Ungate `Config` flag * Review comments --------- Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>

fitzgen requested a review from a team as a code owner January 20, 2026 22:07

fitzgen requested review from dicej and removed request for a team January 20, 2026 22:07

fitzgen force-pushed the concurrent-state-only-when-cm-async branch from e580461 to 617ebec Compare January 20, 2026 22:14

dicej reviewed Jan 20, 2026

View reviewed changes

crates/wasmtime/src/runtime/store.rs Outdated Show resolved Hide resolved

github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jan 21, 2026

fitzgen added 2 commits January 21, 2026 12:40

Support dynamically disabling component-model-async at runtime

3ce619b

fitzgen force-pushed the concurrent-state-only-when-cm-async branch from 617ebec to 3ce619b Compare January 21, 2026 23:18

fix warnings in certain cfg builds

0cea621

fix another warning

cc92218

github-actions bot added the wasmtime:config Issues related to the configuration of Wasmtime label Jan 22, 2026

dicej approved these changes Jan 22, 2026

View reviewed changes

Forcibly enable CM async for a couple wast tests

dc88d45

fitzgen added this pull request to the merge queue Jan 22, 2026

Merged via the queue into bytecodealliance:main with commit 6367989 Jan 22, 2026
45 checks passed

fitzgen deleted the concurrent-state-only-when-cm-async branch January 22, 2026 18:25

alexcrichton reviewed Jan 22, 2026

View reviewed changes

alexcrichton mentioned this pull request Jan 23, 2026

Document panics from using CM async machinery when CM async is not enabled #12393

Closed

alexcrichton mentioned this pull request Jan 23, 2026

Refactor how concurrency support is enabled in a Store #12416

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Only create `ConcurrentState` in a `Store` when CM async is enabled #12377

Only create `ConcurrentState` in a `Store` when CM async is enabled #12377

fitzgen commented Jan 20, 2026

Uh oh!

Uh oh!

fitzgen commented Jan 21, 2026

Uh oh!

github-actions bot commented Jan 22, 2026

Uh oh!

dicej left a comment

Uh oh!

fitzgen commented Jan 22, 2026

Uh oh!

Uh oh!

alexcrichton Jan 22, 2026

Uh oh!

fitzgen Jan 22, 2026

Uh oh!

alexcrichton Jan 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Only create ConcurrentState in a Store when CM async is enabled #12377

Only create ConcurrentState in a Store when CM async is enabled #12377

Conversation

fitzgen commented Jan 20, 2026

Uh oh!

Uh oh!

fitzgen commented Jan 21, 2026

Uh oh!

github-actions bot commented Jan 22, 2026

Label Messager: wasmtime:config

Uh oh!

dicej left a comment

Choose a reason for hiding this comment

Uh oh!

fitzgen commented Jan 22, 2026

Uh oh!

Uh oh!

alexcrichton Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

fitzgen Jan 22, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Only create `ConcurrentState` in a `Store` when CM async is enabled #12377

Only create `ConcurrentState` in a `Store` when CM async is enabled #12377