Skip to content

Shrink the size of the anyfunc table in VMContext#3850

Merged
alexcrichton merged 7 commits into
bytecodealliance:mainfrom
alexcrichton:smaller-anyfunc-table
Feb 28, 2022
Merged

Shrink the size of the anyfunc table in VMContext#3850
alexcrichton merged 7 commits into
bytecodealliance:mainfrom
alexcrichton:smaller-anyfunc-table

Conversation

@alexcrichton

Copy link
Copy Markdown
Member

This commit shrinks the size of the VMCallerCheckedAnyfunc table
allocated into a VMContext to be the size of the number of "escaped"
functions in a module rather than the number of functions in a module.
Escaped functions include exports, table elements, etc, and are
typically an order of magnitude smaller than the number of functions in
general. This should greatly shrink the VMContext for some modules
which while we aren't necessarily having any problems with that today
shouldn't cause any problems in the future.

The original motivation for this was that this came up during the recent
lazy-table-initialization work and while it no longer has a direct
performance benefit since tables aren't initialized at all on
instantiation it should still improve long-running instances
theoretically with smaller VMContext allocations as well as better
locality between anyfuncs.

@github-actions github-actions Bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Feb 25, 2022
@github-actions

Copy link
Copy Markdown

Subscribe to Label Action

cc @peterhuene

Details 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.

@cfallin cfallin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks great, thanks for doing this and sorry I didn't get to it earlier!

Comment thread crates/environ/src/module_environ.rs Outdated
Comment thread crates/environ/src/module_environ.rs Outdated
/// a module compilation.
pub signature: SignatureIndex,
/// The index into the anyfunc table, if present. Note that this is
/// `reserved_value()` if the function does not escape from a module.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What would you think about adding is_escaping(&self) -> bool and non_escaping() -> Self functions for FunctionType, instead of having is_reserved_value() and reserved_value() calls in lots of places? That'd make code using this more self-explanitory.

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct FunctionType {
/// The type of this function, indexed into the global type tables for
/// a module compilation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

"Global" in the comment here is a little ambiguous; would it be correct to say "module-wide" instead?

@github-actions github-actions Bot added the wasmtime:ref-types Issues related to reference types and GC in Wasmtime label Feb 25, 2022
@github-actions

Copy link
Copy Markdown

Subscribe to Label Action

cc @fitzgen

Details This issue or pull request has been labeled: "wasmtime:ref-types"

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

  • fitzgen: wasmtime:ref-types

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

Learn more.

This commit shrinks the size of the `VMCallerCheckedAnyfunc` table
allocated into a `VMContext` to be the size of the number of "escaped"
functions in a module rather than the number of functions in a module.
Escaped functions include exports, table elements, etc, and are
typically an order of magnitude smaller than the number of functions in
general. This should greatly shrink the `VMContext` for some modules
which while we aren't necessarily having any problems with that today
shouldn't cause any problems in the future.

The original motivation for this was that this came up during the recent
lazy-table-initialization work and while it no longer has a direct
performance benefit since tables aren't initialized at all on
instantiation it should still improve long-running instances
theoretically with smaller `VMContext` allocations as well as better
locality between anyfuncs.
@alexcrichton
alexcrichton merged commit 2a6969d into bytecodealliance:main Feb 28, 2022
@alexcrichton
alexcrichton deleted the smaller-anyfunc-table branch February 28, 2022 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:ref-types Issues related to reference types and GC in Wasmtime

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants