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.throwinstructions (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
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.throwinstructions (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
dhil commented on issue #10248:
Tags are added by PR #10251.
alexcrichton added the wasm-proposal:stack-switching label to Issue #10248.
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_switching(from https://github.com/bytecodealliance/wasmtime/pull/10251)
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_switching(from https://github.com/bytecodealliance/wasmtime/pull/10251)
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_switching(from https://github.com/bytecodealliance/wasmtime/pull/10251)- [ ] Update
struct VMContext {...}pseudo-definition comment: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972329164
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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 inwasmtime::Tag::new
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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 inwasmtime::Tag::new: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972341601
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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 inwasmtime::Tag::new: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972341601- [ ] Remove
VMTagImportat the vmcontext level: https://github.com/bytecodealliance/wasmtime/pull/10251/files#r1972423938
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_switching(from https://github.com/bytecodealliance/wasmtime/pull/10251)
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_switching(from https://github.com/bytecodealliance/wasmtime/pull/10251)
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo features to the c-api and various crates/locations there
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo features to the c-api and various crates/locations there
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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#r2127451083Larger 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
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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_switchingwould have a#[cfg]for stack switching on itLarger 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
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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_switchingwould have a#[cfg]for stack switching on itLarger 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
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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_switchingwould have a#[cfg]for stack switching on itLarger 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
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.throwinstructions (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_switchingenables both exceptions + stack-switching, but it should only enablestack_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-switchingCargo 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-switchingCargo 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_switchingwould have a#[cfg]for stack switching on it- [ ]
cont.bindcannot contain gc roots (compile error), see https://github.com/bytecodealliance/wasmtime/pull/11003/files/e9fa92d1fd989a10b584124ca07acee836123b4d#r2138934542Larger 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
dhil commented on issue #10248:
Codegen was added by #11003.
Last updated: Dec 13 2025 at 19:03 UTC