Define VMContext and VMComponentContext in a macro - #14083
Conversation
And automatically generate their offsets, alias region load/store helpers, etc... from the single macro definition. Similar to the existing macro for other `VM*` types, but these definitions are parameterized over a specific Wasm module or component and the entities defined therein.
github-actions
Bot
added
wasmtime:api
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "wasmtime:api", "winch"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
| /// Return a pointer to the collector-specific heap data. | ||
| pub fn gc_heap_data(self: Pin<&mut Self>) -> &mut Option<VmPtr<u8>> { | ||
| let offset = self.offsets().ptr.vmctx_gc_heap_data(); | ||
| let offset = self.offsets().ptr.vmctx().gc_heap_data(); |
There was a problem hiding this comment.
Since accesses like this (throughout the runtime) can be perf-sensitive, have you double-checked that methods are inlined and/or #[inline]'d as needed?
There was a problem hiding this comment.
I marked everything #[inline] but I haven't actually dug through disassemblies -- do you think that is necessary?
There was a problem hiding this comment.
No mostly just want to double-check you were considering this in the implementation. We can always slap #[inline] on things retroactively and we don't have the infrastructure right now to say we should proactively be using #[inline], so "mostly considered during writing" I think is about the best we can do
There was a problem hiding this comment.
FWIW, I'd expect everything here to be just as, if not more, amenable to to LLVM's optimizer.
2 participants
And automatically generate their offsets, alias region load/store helpers, etc... from the single macro definition. Similar to the existing macro for other
VM*types, but these definitions are parameterized over a specific Wasm module or component and the entities defined therein.