Shrink the size of the anyfunc table in VMContext#3850
Conversation
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 |
cfallin
left a comment
There was a problem hiding this comment.
Looks great, thanks for doing this and sorry I didn't get to it earlier!
| /// 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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
"Global" in the comment here is a little ambiguous; would it be correct to say "module-wide" instead?
Subscribe to Label Actioncc @fitzgen DetailsThis issue or pull request has been labeled: "wasmtime:ref-types"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
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.
8a7d19f to
be66271
Compare
This commit shrinks the size of the
VMCallerCheckedAnyfunctableallocated into a
VMContextto 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
VMContextfor some moduleswhich 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
VMContextallocations as well as betterlocality between anyfuncs.