Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement resource support in fact trampolines #6696

Closed
alexcrichton opened this issue Jul 6, 2023 · 0 comments · Fixed by #6769
Closed

Implement resource support in fact trampolines #6696

alexcrichton opened this issue Jul 6, 2023 · 0 comments · Fixed by #6769
Labels
wasm-proposal:component-model Issues related to the WebAssembly Component Model proposal

Comments

@alexcrichton
Copy link
Member

This is an issue to track the work necessary to implement component-to-component calls that use resources. This is the realm of the fact trampoline compiler and I do not plan on adding support for this in the initial implementation of resources at #6691. I am, however, writing down a FIXME in fact to reference this for me to get to it after the first PR lands.
@alexcrichton alexcrichton added the wasm-proposal:component-model Issues related to the WebAssembly Component Model proposal label Jul 6, 2023
@alexcrichton alexcrichton mentioned this issue Jul 14, 2023
Merged
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jul 19, 2023
@alexcrichton
Refactor and simplify component trampolines
667004b 
In poking at bytecodealliance#6696 I felt that the amount of boilerplate for defining
new kinds of trampolines in the component model was getting a bit
excessive. There was already 6 different types and I was adding two more
and I had to touch just a few too many places to get this done. In the
end I decided to refactor how trampolines are handled in the component
model to make it much easier to add new kinds of trampolines.

To that end the type-specific counts/lists/etc are all gone now in favor
of a single concept of a trampoline. This means components now track
trampolines in-bulk rather than individually by type. For example
compiling trampolines is now a loop over "compile this list of
trampolines" where previously it was N loops for the N types of
trampolines. The `Trampoline` definition is where the enum and dispatch
happens where that contains all possible trampolines that a component
could require.

This ended up being a large refactor to the Cranelift component
integration, but there is not intended to be any functional change from
this refactoring. Additionally all trampolines are now removed from the
global initializers list since there's nothing preventing them from
being initialized earlier on during the instantiation process.

Overall this should drastically reduce the number of locations that need
to have trampoline-specific knowledge to translation, the dataflow
graph, and compilation. Nearly everything else can operate over
everything in bulk and forward between these systems.
@alexcrichton alexcrichton mentioned this issue Jul 19, 2023
Merged
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jul 24, 2023
@alexcrichton
Refactor and simplify component trampolines
0df191a 
In poking at bytecodealliance#6696 I felt that the amount of boilerplate for defining
new kinds of trampolines in the component model was getting a bit
excessive. There was already 6 different types and I was adding two more
and I had to touch just a few too many places to get this done. In the
end I decided to refactor how trampolines are handled in the component
model to make it much easier to add new kinds of trampolines.

To that end the type-specific counts/lists/etc are all gone now in favor
of a single concept of a trampoline. This means components now track
trampolines in-bulk rather than individually by type. For example
compiling trampolines is now a loop over "compile this list of
trampolines" where previously it was N loops for the N types of
trampolines. The `Trampoline` definition is where the enum and dispatch
happens where that contains all possible trampolines that a component
could require.

This ended up being a large refactor to the Cranelift component
integration, but there is not intended to be any functional change from
this refactoring. Additionally all trampolines are now removed from the
global initializers list since there's nothing preventing them from
being initialized earlier on during the instantiation process.

Overall this should drastically reduce the number of locations that need
to have trampoline-specific knowledge to translation, the dataflow
graph, and compilation. Nearly everything else can operate over
everything in bulk and forward between these systems.
github-merge-queue bot pushed a commit that referenced this issue Jul 24, 2023
@alexcrichton
Refactor and simplify component trampolines (#6751)
f4eeb02 
In poking at #6696 I felt that the amount of boilerplate for defining
new kinds of trampolines in the component model was getting a bit
excessive. There was already 6 different types and I was adding two more
and I had to touch just a few too many places to get this done. In the
end I decided to refactor how trampolines are handled in the component
model to make it much easier to add new kinds of trampolines.

To that end the type-specific counts/lists/etc are all gone now in favor
of a single concept of a trampoline. This means components now track
trampolines in-bulk rather than individually by type. For example
compiling trampolines is now a loop over "compile this list of
trampolines" where previously it was N loops for the N types of
trampolines. The `Trampoline` definition is where the enum and dispatch
happens where that contains all possible trampolines that a component
could require.

This ended up being a large refactor to the Cranelift component
integration, but there is not intended to be any functional change from
this refactoring. Additionally all trampolines are now removed from the
global initializers list since there's nothing preventing them from
being initialized earlier on during the instantiation process.

Overall this should drastically reduce the number of locations that need
to have trampoline-specific knowledge to translation, the dataflow
graph, and compilation. Nearly everything else can operate over
everything in bulk and forward between these systems.
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Jul 25, 2023
@alexcrichton
Implement component-to-component calls with resources
f44165d 
This fills out support in FACT in Wasmtime to support
component-to-component calls that use resources. This ended up being
relatively simple as it's "just" a matter of moving resources between
tables which at this time bottoms out in calls to the host. These new
trampolines are are relatively easy to add after bytecodealliance#6751 which helps keep
this change contained.

Closes bytecodealliance#6696
@alexcrichton alexcrichton mentioned this issue Jul 25, 2023
Merged
github-merge-queue bot pushed a commit that referenced this issue Jul 25, 2023
@alexcrichton
Implement component-to-component calls with resources (#6769)
71d0418 
* Implement component-to-component calls with resources

This fills out support in FACT in Wasmtime to support
component-to-component calls that use resources. This ended up being
relatively simple as it's "just" a matter of moving resources between
tables which at this time bottoms out in calls to the host. These new
trampolines are are relatively easy to add after #6751 which helps keep
this change contained.

Closes #6696

* Review comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
wasm-proposal:component-model Issues related to the WebAssembly Component Model proposal
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Implement component-to-component calls with resources alexcrichton/wasmtime
1 participant
@alexcrichton