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.
This is a preliminary PR, posted for review and comments. Do not merge yet.
It is a followup PR to #1506 that includes it, so you should (a) go read it first and (b) just look at the second commit in this PR when considering its content.
The goal here is to support wasmtime's new winch single-pass compiler as an alternative backend for soroban. It works well enough to run contracts, though it's still quite rough and needs a lot of tuning and polish, and winch itself is not entirely complete either. But it's a promising enough experiment that I wanted to get it stabilized enough to merge -- cfg'ed-off -- while we continue to iterate and experiment with it.
It depends on #1506 because even a single-pass JIT like winch is still orders of magnitude slower to compile code than wasmi is to translate to its IR; high enough latency that it can only possibly makes sense if we have a longer-lived
ModuleCache
. In fact caching logic (and how to pay for caching) has been one of the substantial barriers to considering JITs up until now, but we have recently had some fairly novel thoughts on how to handle that problem space. So here we are!The second commit here that does the wasmtime/winch addition is relatively straightforward, once the caching is taken care of. There are some wrinkles around the different gas-transfer API, the different ways of plumbing errors, interacting with linear memory, wrapping dispatch functions, spelling primitive value types, and so forth; but wasmi was built to mirror the wasmtime API fairly closely. For the most part we just "make a new wasmtime object corresponding to any existing wasmi object".
(The code duplication in the dispatch macro and the vm invocation path is especially unfortunate, I can probably factor those a little harder before this is finalized but I wanted to at least get it running and there were a lot of fiddly bits.)