wasmtime / issue #10248 Tracking issue: Stack switching p... · git-wasmtime · Zulip Chat Archive

Stream: git-wasmtime

Topic: wasmtime / issue #10248 Tracking issue: Stack switching p...

Wasmtime GitHub notifications bot (Feb 19 2025 at 23:13):

frank-emrich opened issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[ ] Support for tags

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

Support for ISAs other than x64

Support for resume.throw instructions (requires exception handling)

Support for deallocating continuations

Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

Windows support

Pulley support

Winch support

Wasmtime GitHub notifications bot (Feb 19 2025 at 23:15):

frank-emrich edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[ ] Support for tags

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Wasmtime GitHub notifications bot (Feb 20 2025 at 12:51):

dhil commented on issue #10248:

Tags are added by PR #10251.

Wasmtime GitHub notifications bot (Feb 20 2025 at 15:39):

alexcrichton added the wasm-proposal:stack-switching label to Issue #10248.

Wasmtime GitHub notifications bot (Feb 20 2025 at 15:48):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[ ] Support for tags

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

Wasmtime GitHub notifications bot (Feb 20 2025 at 23:03):

frank-emrich edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

Wasmtime GitHub notifications bot (Feb 26 2025 at 20:10):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] Update struct VMContext {...} pseudo-definition comment: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972329164

Wasmtime GitHub notifications bot (Feb 26 2025 at 20:18):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] Update struct VMContext {...} pseudo-definition comment: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972329164

[ ] Return an Err(_) if the given function type has results in wasmtime::Tag::new

Wasmtime GitHub notifications bot (Feb 26 2025 at 20:19):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] Update struct VMContext {...} pseudo-definition comment: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972329164

[ ] Return an Err(_) if the given function type has results in wasmtime::Tag::new: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972341601

Wasmtime GitHub notifications bot (Feb 26 2025 at 21:16):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] Update struct VMContext {...} pseudo-definition comment: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972329164

[ ] Return an Err(_) if the given function type has results in wasmtime::Tag::new: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972341601

[ ] Remove VMTagImport at the vmcontext level: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972423938

Wasmtime GitHub notifications bot (Feb 27 2025 at 20:06):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[ ] Type definitions for stack switching support

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

Wasmtime GitHub notifications bot (Mar 07 2025 at 20:11):

frank-emrich edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

Wasmtime GitHub notifications bot (Jun 04 2025 at 22:45):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[ ] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

Wasmtime GitHub notifications bot (Jun 05 2025 at 15:07):

posborne edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

Wasmtime GitHub notifications bot (Jun 05 2025 at 15:29):

posborne edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion.

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Jun 05 2025 at 15:53):

posborne edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[ ] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion.

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Jun 05 2025 at 23:01):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[ ] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion.

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Jun 09 2025 at 15:03):

posborne edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion.

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Jun 10 2025 at 18:15):

fitzgen edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion. (Note: This will likely mean that stack switching will require cfg(feature = "async") which is what we probably want anyways)

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Jun 11 2025 at 19:23):

posborne edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

[ ] cont.bind cannot contain gc roots (compile error), see https://github.com/bytecodealliance/wasmtime/pull/11003/files/e9fa92d1fd989a10b584124ca07acee836123b4d#r2138934542

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion. (Note: This will likely mean that stack switching will require cfg(feature = "async") which is what we probably want anyways)

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Sep 16 2025 at 16:35):

dhil commented on issue #10248:

Codegen was added by #11003.

Wasmtime GitHub notifications bot (Apr 09 2026 at 20:17):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

[ ] cont.bind cannot contain gc roots (compile error), see https://github.com/bytecodealliance/wasmtime/pull/11003/files/e9fa92d1fd989a10b584124ca07acee836123b4d#r2138934542

[ ] https://github.com/bytecodealliance/wasmtime/issues/13020

[ ] https://github.com/bytecodealliance/wasmtime/issues/13021

[ ] https://github.com/bytecodealliance/wasmtime/issues/13022

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion. (Note: This will likely mean that stack switching will require cfg(feature = "async") which is what we probably want anyways)

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Apr 09 2026 at 20:18):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

[ ] cont.bind cannot contain gc roots (compile error), see https://github.com/bytecodealliance/wasmtime/pull/11003/files/e9fa92d1fd989a10b584124ca07acee836123b4d#r2138934542

[ ] https://github.com/bytecodealliance/wasmtime/issues/13020

[ ] https://github.com/bytecodealliance/wasmtime/issues/13021

[ ] https://github.com/bytecodealliance/wasmtime/issues/13022

[ ] all test cases at https://gist.github.com/alexcrichton/c03760ee0d0a1c37a15f2e1cd27060d4 currently fail

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion. (Note: This will likely mean that stack switching will require cfg(feature = "async") which is what we probably want anyways)

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Apr 09 2026 at 21:20):

alexcrichton edited issue #10248:

This is a tracking issue for the in-progress implementation of the Wasm stack switching proposal. The explainer document for the proposal is here.

Progress of initial implementation

This just tracks what's happening in the sequence of PRs that's providing an initial implementation of the proposal. To get an idea of the extent of the initial implementation, see draft PR #10177.

[x] ~Support for tags~ (implemented in #10251)

[x] ~Type definitions for stack switching support~ (implemented in #10255)

[x] Runtime support for stack switching (implemented in #10388)

[ ] Compiling stack switching instructions to CLIF

Limitations of initial implementation

These are things that won't be part of the initial implementation:

[ ] Support for ISAs other than x64

[ ] Support for resume.throw instructions (requires exception handling)

[ ] Support for deallocating continuations

[ ] Integration with GC (i.e., allowing continuation references to appear in GC objects, such as arrays an structs)

[ ] Windows support

[ ] Pulley support

[ ] Winch support

Miscellaneous TODO items

[ ] Config::wasm_stack_switching enables both exceptions + stack-switching, but it should only enable stack_switching (from https://github.com/bytecodealliance/wasmtime/pull/10251)

[ ] After pulley support, update the provenance test to exercise various bits of stack switching to run as much as we can through MIRI

[ ] Update the host_segfault.rs test to exercise stack overflow cases in various stack-y situations to ensure that faults due to misconfigured engines or recursion on the host fail in predictable fashions

[ ] Remove use of rustix::param::page_size (cc https://github.com/bytecodealliance/wasmtime/pull/10803 for motivation)

[ ] Remove stack-switching Cargo features for winch/Cranelift-related crates. Keep it for runtime bits, but for compiler bits we've generally found it's not worth the overhead.

[ ] Add stack-switching Cargo features to the c-api and various crates/locations there

[ ] Stack-capturing fuzzer needs to be extended to support capturing backtraces across stack suspensions

[ ] Add support for stack switching in the embedder API (https://github.com/bytecodealliance/wasmtime/pull/10388#discussion_r1994307521).

[ ] Allow basic compat of GC/stack-switching (continuations will still have lifetime of store).

[x] Remove stray DeleteMeDebugAssertions: https://github.com/bytecodealliance/wasmtime/pull/10388/files/60c9cdb707fc674857fa549a8459f8c602be0c82#r2127451083

[ ] Ideally mod stack_switching would have a #[cfg] for stack switching on it

[ ] cont.bind cannot contain gc roots (compile error), see https://github.com/bytecodealliance/wasmtime/pull/11003/files/e9fa92d1fd989a10b584124ca07acee836123b4d#r2138934542

[ ] https://github.com/bytecodealliance/wasmtime/issues/13020

[ ] https://github.com/bytecodealliance/wasmtime/issues/13021

[ ] https://github.com/bytecodealliance/wasmtime/issues/13022

[ ] all test cases at https://gist.github.com/alexcrichton/c03760ee0d0a1c37a15f2e1cd27060d4 currently fail

[ ] https://github.com/bytecodealliance/wasmtime/issues/13028

Larger outstanding work items which have arisen during review of the initial changes:

[ ] Hostcalls can currently be made directly from continuation stacks; this behavior is different than the fibers impl and we likely should not allow this, see related discussion

[ ] Currently stack switching and fibers use different stack layouts and cannot (without modification) share a lot of functionality (e.g. pooling allocator used for fiber stacks); long-term, we would like to unify these two mechanisms where possible. See discussion. (Note: This will likely mean that stack switching will require cfg(feature = "async") which is what we probably want anyways)

[ ] Implement full GC of continuations

Wasmtime GitHub notifications bot (Aug 15 2026 at 07:11):

smarcd commented on issue #10248:

Two embedder-API requirements, in case they're useful input while the shape of that API is still open (I saw @fitzgen's "add an item to the meta task list for the embedder API" note on #10388 — doesn't look like that's been fleshed out yet). Both come up for any embedder targeting real POSIX/C compatibility on top of Wasm:

1. setjmp/longjmp

Wasm has no native non-local control transfer, so this currently has to be faked — either via Asyncify's whole-program stack-copying transform, or an equivalent host-driven suspend/resume shim. That's a real, generalizable cost (code size, compile time, and runtime overhead on every function that might be unwound through, not just the ones that are). WASIX is a concrete existing example of this: it implements POSIX longjmp (and fork) on Wasm this way, via Asyncify in Wasmer, as far as I'm aware the only runtime to have actually shipped that spec so far — which suggests the cost is being paid for real, not just hypothetically. It'd be good to confirm, as the embedder API takes shape, that its suspend/resume primitives are actually sufficient to implement setjmp/longjmp-style non-local jumps directly on top of continuations — i.e. that this is a design goal, not just an accident of what the API happens to support.

2. Duplicating a live continuation (fork-style semantics)

A runtime that wants fork() semantics needs to duplicate a live, suspended execution context into a fresh instance — not just resume the same continuation later, but produce two independently-resumable copies of it, one of which continues in a different instance. As far as I can tell nothing in the proposal or the embedder-API discussion so far addresses whether a continuation can be captured/inspected/cloned rather than only linearly resumed once. This seems worth deciding deliberately now, while the API is still unspecified, rather than discovering later that the natural implementation only supports single-shot resume.

Happy to go into more detail on either of these if it's useful — we'd genuinely like to see this land and would rather raise real embedder requirements early than after the API shape is locked in.

Wasmtime GitHub notifications bot (Aug 15 2026 at 07:17):

bjorn3 commented on issue #10248:

This would be better directed at the stack switching proposal repo than at wasmtime. In any case re point 2, they are linear: https://github.com/WebAssembly/stack-switching/blob/main/proposals/stack-switching/Explainer.md#one-shot-continuations

Last updated: Aug 30 2026 at 09:07 UTC