-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
Refactor store frame information. #2811
Refactor store frame information. #2811
Conversation
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
This 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, Peter!
* 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.
Requesting re-review for the new commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
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 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 PR refactors the store frame information to eliminate the copying of
data out from
CompiledModule
.It also removes the population of a
BTreeMap
in 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.