Refactor store frame information.#2811
Merged
peterhuene merged 2 commits intoApr 8, 2021
Merged
Conversation
peterhuene
commented
Apr 7, 2021
This commit refactors the store frame information to eliminate the copying of data out from `CompiledModule`. It also moves the population of a `BTreeMap` out of the frame information and into `CompiledModule` where it is only ever calculated once rather than at every new module instantiation into a `Store`. The map is also lazy-initialized so the cost of populating the map is incurred only when a trap occurs. This should help improve instantiation time of modules with a large number of functions and functions with lots of instructions.
84dac5a to
875cb92
Compare
Subscribe to Label Actioncc @peterhuene DetailsThis issue or pull request has been labeled: "wasmtime:api"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
reviewed
Apr 7, 2021
Member
alexcrichton
left a comment
There was a problem hiding this comment.
Nice! I'm curious if we can actually remove this whole map entirely...
(this frame-info stuff has changed so many times every time someone looks at it it feels like there's inevitably a few more possible optimizations here and there)
* Remove `once-cell` dependency. * Remove function address `BTreeMap` from `CompiledModule` in favor of binary searching finished functions directly. * Use `with_capacity` when populating `CompiledModule` finished functions and trampolines.
Member
Author
|
Requesting re-review for the new commit. |
fitzgen
approved these changes
Apr 8, 2021
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Apr 8, 2021
This commit fixes a perf issue I was seeing in some local benchmarking where registration of stack maps took a nontrivial amount of time for a module that didn't even use stack maps! The fix here is to largely just do the same thing as bytecodealliance#2811 which is to use the in-memory data structures of a `CompiledModule` rather than rebuilding different data structures when a module is registered with a `Store`. The `StackMapRegistry` type now takes a lookup object for a range of pcs, simplifying registration. Registration additionally doesn't even happen if a module is pre-determined to not have any stack maps inside of it. This trait object encapsulates all the logic that was previously used in the rebuilt data structures and also leverages conveniences like `CompiledModule::func_by_pc` added recently as well. With this all combined it means that modules which don't have stack maps now skip this registration step entirely and modules with stack maps should do much less work during registration as well.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Apr 8, 2021
This commit fixes a perf issue I was seeing in some local benchmarking where registration of stack maps took a nontrivial amount of time for a module that didn't even use stack maps! The fix here is to largely just do the same thing as bytecodealliance#2811 which is to use the in-memory data structures of a `CompiledModule` rather than rebuilding different data structures when a module is registered with a `Store`. The `StackMapRegistry` type now takes a lookup object for a range of pcs, simplifying registration. Registration additionally doesn't even happen if a module is pre-determined to not have any stack maps inside of it. This trait object encapsulates all the logic that was previously used in the rebuilt data structures and also leverages conveniences like `CompiledModule::func_by_pc` added recently as well. With this all combined it means that modules which don't have stack maps now skip this registration step entirely and modules with stack maps should do much less work during registration as well.
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
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 the store frame information to eliminate the copying of
data out from
CompiledModule.It also removes the population of a
BTreeMapin favor of doing a binarysearch on the finished functions in the associated
CompiledModule.This should help improve instantiation time of modules with a large number of
functions and functions with lots of instructions.