Have a single table for resources, waitables, waitable sets, etc#513
Merged
lukewagner merged 1 commit intomainfrom May 5, 2025
Merged
Have a single table for resources, waitables, waitable sets, etc#513lukewagner merged 1 commit intomainfrom
lukewagner merged 1 commit intomainfrom
Conversation
alexcrichton
approved these changes
May 1, 2025
dicej
added a commit
to dicej/wasmtime
that referenced
this pull request
Aug 1, 2025
Per WebAssembly/component-model#513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match. - Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure - Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables` - Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above - Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables` Fixes bytecodealliance#11189 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/wasmtime
that referenced
this pull request
Aug 1, 2025
Per WebAssembly/component-model#513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match. - Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure - Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables` - Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above - Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables` While I was doing table-related things, I also updated `concurrent::Table::new` to reserve the zero handle to mean "invalid". This won't affect what the guest sees in any way, but it allows us to use `TableId::new(0)` to invalidate host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`. Fixes bytecodealliance#11189 Signed-off-by: Joel Dice <joel.dice@fermyon.com>
dicej
added a commit
to dicej/wasmtime
that referenced
this pull request
Aug 12, 2025
Per WebAssembly/component-model#513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match. - Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure - Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables` - Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above - Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables` While I was doing table-related things, I also updated `concurrent::Table::new` to reserve the zero handle to mean "invalid". This won't affect what the guest sees in any way, but it allows us to use `TableId::new(0)` to invalidate host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`. Fixes bytecodealliance#11189 Signed-off-by: Joel Dice <joel.dice@fermyon.com> Re-internalize `ResourceKind` to `mod handle_table` Remove `ResourceKind` Start flattening the representation of `Slot` Internalize `get_mut_handle_by_index` Internalize implementation details such as the representation of slots to and make methods a bit more targeted in their functionality. Internalize more details of `HandleTable` Don't expose `HandleKind` and of per-function methods for operating on the various kinds of handles that reside in the table. Flatten the representation of `Slot` There's still some more work to do for host/guest resource handles, but this helps realize the goal of the previous refactorings in the meantime.
github-merge-queue bot
pushed a commit
to bytecodealliance/wasmtime
that referenced
this pull request
Aug 12, 2025
* use a single table per instance for resources, waitables, etc. Per WebAssembly/component-model#513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match. - Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure - Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables` - Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above - Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables` While I was doing table-related things, I also updated `concurrent::Table::new` to reserve the zero handle to mean "invalid". This won't affect what the guest sees in any way, but it allows us to use `TableId::new(0)` to invalidate host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`. Fixes #11189 Signed-off-by: Joel Dice <joel.dice@fermyon.com> Re-internalize `ResourceKind` to `mod handle_table` Remove `ResourceKind` Start flattening the representation of `Slot` Internalize `get_mut_handle_by_index` Internalize implementation details such as the representation of slots to and make methods a bit more targeted in their functionality. Internalize more details of `HandleTable` Don't expose `HandleKind` and of per-function methods for operating on the various kinds of handles that reside in the table. Flatten the representation of `Slot` There's still some more work to do for host/guest resource handles, but this helps realize the goal of the previous refactorings in the meantime. * stop using `HandleTable::reps_to_indexes` when delivering events Per review feedback, we'd like to get rid of `HandleTable::reps_to_indexes` entirely. This commit doesn't go quite that far, but now we only use it for `error-context` handles. For waitables, which can only be referenced by at most one guest at a time, we now store the guest handle in `WaitableCommon::handle` and retrieve it from there when delivering an event for that waitable. For `error-context` handles, the spec requirement that we always lower the same handle for the same `error-context`, combined with the fact that an `error-context` may be referenced by more than one component instance at a time, means we still need some general way to convert a host rep plus component index into a handle. Going forward, we could consider either removing that "same handle" requirement from the spec or consider an alternative implementation (e.g. storing a `HashMap<RuntimeComponentIndex, usize>` in the `ErrorContext` host state for keeping track of the handles for each referencing instance. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove `HandleTable::reps_to_indexes` Turns out the spec no longer requires that guests receive the same handle for a given `error-context` as the one they already have, so we no longer need this field -- nor do we need to maintain a per-component-instance reference count. Signed-off-by: Joel Dice <joel.dice@fermyon.com> --------- Signed-off-by: Joel Dice <joel.dice@fermyon.com>
9 tasks
bongjunj
pushed a commit
to prosyslab/wasmtime
that referenced
this pull request
Oct 20, 2025
…odealliance#11374) * use a single table per instance for resources, waitables, etc. Per WebAssembly/component-model#513, the spec now puts resources, waitables, waitable sets, subtasks, and error contexts in the same table per instance. This updates the implementation to match. - Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure - Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables` - Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above - Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables` While I was doing table-related things, I also updated `concurrent::Table::new` to reserve the zero handle to mean "invalid". This won't affect what the guest sees in any way, but it allows us to use `TableId::new(0)` to invalidate host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`. Fixes bytecodealliance#11189 Signed-off-by: Joel Dice <joel.dice@fermyon.com> Re-internalize `ResourceKind` to `mod handle_table` Remove `ResourceKind` Start flattening the representation of `Slot` Internalize `get_mut_handle_by_index` Internalize implementation details such as the representation of slots to and make methods a bit more targeted in their functionality. Internalize more details of `HandleTable` Don't expose `HandleKind` and of per-function methods for operating on the various kinds of handles that reside in the table. Flatten the representation of `Slot` There's still some more work to do for host/guest resource handles, but this helps realize the goal of the previous refactorings in the meantime. * stop using `HandleTable::reps_to_indexes` when delivering events Per review feedback, we'd like to get rid of `HandleTable::reps_to_indexes` entirely. This commit doesn't go quite that far, but now we only use it for `error-context` handles. For waitables, which can only be referenced by at most one guest at a time, we now store the guest handle in `WaitableCommon::handle` and retrieve it from there when delivering an event for that waitable. For `error-context` handles, the spec requirement that we always lower the same handle for the same `error-context`, combined with the fact that an `error-context` may be referenced by more than one component instance at a time, means we still need some general way to convert a host rep plus component index into a handle. Going forward, we could consider either removing that "same handle" requirement from the spec or consider an alternative implementation (e.g. storing a `HashMap<RuntimeComponentIndex, usize>` in the `ErrorContext` host state for keeping track of the handles for each referencing instance. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove `HandleTable::reps_to_indexes` Turns out the spec no longer requires that guests receive the same handle for a given `error-context` as the one they already have, so we no longer need this field -- nor do we need to maintain a per-component-instance reference count. Signed-off-by: Joel Dice <joel.dice@fermyon.com> --------- Signed-off-by: Joel Dice <joel.dice@fermyon.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As discussed in #511 this closes a discrepancy with the implementation and completes a transition started with #427.