Skip to content

Runtime Implementation Supporting the Sync ABI - #38

Open
jeremyg484 wants to merge 1 commit into
roastedroot:mainfrom
jeremyg484:extract-runtime-for-pr
Open

Runtime Implementation Supporting the Sync ABI#38
jeremyg484 wants to merge 1 commit into
roastedroot:mainfrom
jeremyg484:extract-runtime-for-pr

Conversation

@jeremyg484

Copy link
Copy Markdown
Collaborator

The runtime module is built out to what is believed to be a functionally correct implementation for any component that is using the sync ABI. This is essentially equivalent to the level of internal runtime support needed to support WASIp2. Work on host-side WASIp2 implementation (and the supporting compile-time wit-bindgen infrastructure and additional user-facing API surface that would be necessary) is left to be the next major phase of work.

This implementation passes all of the tests from the Component Model spec repo (save for a handful of documented exceptions) that do not require async support.

The support for the spec test suite is enhanced to more rigorously enforce the assertions therein, fully comparing messages of expected error cases and exercising the full parsing, instantiation, and function invocation pipeline wherever required by the tests.

A Validator interface is introduced to the Parser module, and an implementation is required to be provided by default. The tests provide an implementation that uses the ComponentValidate wasm-tools class to validate the binary form of a component before parsing. Additional validations that must be applied after parsing in order to meet certain expectations of the spec test suite are provided as a default method in the interface.

The ComponentLinker is the main API surface for instantiating components. It processes the parsed component's sections in order and wires everything together, performing the necessary lifting and lowering as specified by the Canonical ABI. It works under the assumption that a component binary has already been validated by something such as wasm-tools. It performs extensive type checking of imports at the host boundary, enforcing the inter-component contracts that cannot be validated by wasm-tools' view of a single component binary.

To achieve type-checking more efficiently, sort indices in the parsed AST are resolved as they are encountered by the ComponentLinker, relying upon the spec rule that an index always references a preceding definition. This results in reduced complexity in the canonical-abi module as well, and its API contracts have been refactored to work with these fully resolved types.

The relationship between a ComponentInstance and its ComponentStore is evolved from the original skeleton runtime implementation. A ComponentInstance now manages its own state and index spaces rather than delegating to the store. There is now a 1:N relationship between the ComponentStore and ComponentInstances. This aligns more with how the Store is described in the specification and matches the approach that Wasmtime has taken.

The runtime module is built out to what is believed to be a functionally
correct implementation for any component that is using the sync ABI.
This is essentially equivalent to the level of internal runtime support
needed to support WASIp2. Work on host-side WASIp2 implementation (and
the supporting compile-time wit-bindgen infrastructure and additional
user-facing API surface that would be necessary) is left to be the next
major phase of work.

This implementation passes all of the tests from the Component Model
spec repo (save for a handful of documented exceptions) that do not
require async support.

The support for the spec test suite is enhanced to more rigorously
enforce the assertions therein, fully comparing messages of expected
error cases and exercising the full parsing, instantiation, and
function invocation pipeline wherever required by the tests.

A Validator interface is introduced to the Parser module, and an
implementation is required to be provided by default. The tests provide
an implementation that uses the ComponentValidate wasm-tools class to
validate the binary form of a component before parsing. Additional
validations that must be applied after parsing in order to meet certain
expectations of the spec test suite are provided as a default method in
the interface.

The ComponentLinker is the main API surface for instantiating
components. It processes the parsed component's sections in order and
wires everything together, performing the necessary lifting and lowering
as specified by the Canonical ABI. It works under the assumption that a
component binary has already been validated by something such as
wasm-tools. It performs extensive type checking of imports at the host
boundary, enforcing the inter-component contracts that cannot be
validated by wasm-tools' view of a single component binary.

To achieve type-checking more efficiently, sort indices in the parsed
AST are resolved as they are encountered by the ComponentLinker, relying
upon the spec rule that an index always references a preceding
definition. This results in reduced complexity in the canonical-abi
module as well, and its API contracts have been refactored to work with
these fully resolved types.

The relationship between a ComponentInstance and its ComponentStore is
evolved from the original skeleton runtime implementation. A
ComponentInstance now manages its own state and index spaces rather than
delegating to the store. There is now a 1:N relationship between the
ComponentStore and ComponentInstances. This aligns more with how the
Store is described in the specification and matches the approach that
Wasmtime has taken.
@jeremyg484
jeremyg484 requested a review from andreaTP August 24, 2026 21:17
@jeremyg484

Copy link
Copy Markdown
Collaborator Author

@andreaTP My apologies in advance for the large size of this PR. It was going to be unavoidably large just from the runtime build-out, but then as I was revising and implementing import type checking, some refactoring to canonical-abi also proved necessary. No rush to review, I'm going to be pretty swamped with other work for the remainder of this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant