Refactor module instantiation in the runtime. #2454
Closed
Conversation
This file contains 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
github-actions
bot
added
cranelift
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "cranelift", "cranelift:wasm", "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
This PR also tries to reduce allocations and copying:
|
fitzgen
reviewed
Nov 30, 2020
peterhuene
force-pushed
the
instance-pooling
branch
3 times, most recently
from
dc78ba1
to
2ede8e4
Compare
alexcrichton
approved these changes
Dec 2, 2020
peterhuene
force-pushed
the
instance-pooling
branch
from
686c592
to
1978b43
Compare
peterhuene
commented
Dec 3, 2020
peterhuene
force-pushed
the
instance-pooling
branch
4 times, most recently
from
4a02a11
to
17ef987
Compare
peterhuene
force-pushed
the
instance-pooling
branch
5 times, most recently
from
489e00a
to
a2813b1
Compare
peterhuene
force-pushed
the
instance-pooling
branch
4 times, most recently
from
af4b3d4
to
bb33260
Compare
peterhuene
force-pushed
the
instance-pooling
branch
3 times, most recently
from
0f7431c
to
c08be37
Compare
This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures.
Turns out this is another caller-saved register!
Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses.
With fuel it's probably best to not provide any way to inject infinite fuel.
This commit refactors module instantiation in the runtime to allow for different instance allocation strategy implementations. It adds an `InstanceAllocator` trait with the current implementation put behind the `OnDemandInstanceAllocator` struct. The Wasmtime API has been updated to allow a `Config` to have an instance allocation strategy set which will determine how instances get allocated. This change is in preparation for an alternative *pooling* instance allocator that can reserve all needed host process address space in advance. This commit also makes changes to the `wasmtime_environ` crate to represent compiled modules in a way that reduces copying at instantiation time.
This commit introduces two new methods on `InstanceAllocator`: * `validate_module` - this method is used to validate a module after translation but before compilation. It will be used for the upcoming pooling allocator to ensure a module being compiled adheres to the limits of the allocator. * `adjust_tunables` - this method is used to adjust the `Tunables` given the JIT compiler. The pooling allocator will use this to force all memories to be static during compilation.
This commit refactors `Table` in the runtime such that it can be created from a pointer to existing table data. The current `Vec` backing of the `Table` is considered to be "dynamic" storage. This will be used for the upcoming pooling allocator where table memory is managed externally to the instance. The `table.copy` implementation was improved to use slice primitives for doing the copying. Fixes bytecodealliance#983.
This commit changes how memories and tables are stored in `Instance`. Previously, the memories and tables were stored as a `BoxedSlice`. Storing it this way requires an allocation to change the length of the memories and tables, which is desirable for a pooling instance allocator that is reusing an `Instance` structure for a new instantiation. By storing it instead as `PrimaryMap`, the memories and tables can be resized without any allocations (the capacity of these maps will always be the configured limits of the pooling allocator).
This commit changes `Instance` such that memories can be stored statically, with just a base pointer, size, maximum, and a callback to make memory accessible. Previously the memories were being stored as boxed trait objects, which would require the pooling allocator to do some unpleasant things to avoid allocations. With this change, the pooling allocator can simply define a memory for the instance without using a trait object.
Handles created with `create_handle` need to be deallocated with the default (on-demand) instance allocator. This commit changes Store such that handles can be added with a flag that is used to force deallocation via the default instance allocator when the Store is dropped.
With the change to artificially limit unbounded memories based on Tunables, it's possible to hit the assert where the minimum might exceed the static memory bound. This commit removes the assert in favor of a check to see if the minimum also fits within the static memory bound. It also corrects the maximum bounding to ensure the minimum between the memory's maximum and the configured maximum is used. If it does not fit, the memory will be treated as dynamic. In the case of the pooling instance allocator, the bounds will be checked again during translation and an appropriate error will be returned as dynamic memories are not supported for that allocator.
peterhuene
force-pushed
the
instance-pooling
branch
5 times, most recently
from
5e34198
to
697f4c0
Compare
This commit implements allocating fiber stacks in an instance allocator. The on-demand instance allocator doesn't support custom stacks, so the implementation will use the allocation from `wasmtime-fiber` for the fiber stacks. In the future, the pooling instance allocator will return custom stacks to use on Linux and macOS. On Windows, the native fiber implementation will always be used.
peterhuene
force-pushed
the
instance-pooling
branch
from
697f4c0
to
3107349
Compare
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:c-api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
|
Closing this PR in favor of #2518. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR refactors module instantiation in the runtime to allow for
different instance allocation strategy implementations.
It adds an
InstanceAllocatortrait with the current implementation put behindthe
OnDemandInstanceAllocatorstruct.The Wasmtime API has been updated to allow a
Configto have an instanceallocation strategy set which will determine how instances get allocated.
This change is in preparation for an alternative pooling instance allocator
that can reserve all needed host process address space in advance.
This PR also makes changes to the
wasmtime_environcrate to representcompiled modules in a way that reduces copying at instantiation time.
See bytecodealliance/rfcs#5 about these proposed changes.
This PR depends on #2434.