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.

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

Merged

Conversation

peterhuene
Copy link
Member

@peterhuene peterhuene commented Apr 7, 2021

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 binary
search 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.

@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label 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.
@github-actions
Copy link

github-actions bot commented Apr 7, 2021

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

Copy link
Member

@alexcrichton alexcrichton left a 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)

crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
crates/wasmtime/src/frame_info.rs Show resolved Hide resolved
Copy link
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, Peter!

crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
* 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.
@peterhuene
Copy link
Member Author

Requesting re-review for the new commit.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label Apr 8, 2021
@peterhuene peterhuene merged commit 45a5007 into bytecodealliance:main Apr 8, 2021
@peterhuene peterhuene deleted the improve-store-registration branch April 8, 2021 01:16
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator wasmtime:api Related to the API of the `wasmtime` crate itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants