Stream: git-wasmtime

Topic: wasmtime / issue #4191 Don't recalculate `VMOffsets` each...

Wasmtime GitHub notifications bot (May 27 2022 at 18:22):

alexcrichton opened issue #4191:

Currently whenever an instance is created Wasmtime will calculate the VMOffsets structure (also for the pooling allocator). This VMOffsets structure which is actually quite large is also stored within the Instance allocation for each instance. This means that every instantiation is redoing this work and additionally "wasting" space by storing this in each Instance. While the cost of computation here and the cost of initializing this storage is pretty small I think this would still be good to fix.

I think a better solution would be to perhaps store the VMOffsets in the runtime_info field since this information is statically known when the module is created and it can live in one location in the module and be referenced indirectly by each instance. The reason I hesitate to do this though is that accessing the vmoffsets would then become a dynamic function call (since ModuleRuntimeInfo is a trait). as opposed to today where information is at a static offset within Instance. I'm worried about the runtime impact of naively moving this information behind ModuleRuntimeInfo (since VMOffsets is pretty hot).

I'm not sure how best to solve this immediately, but some possibilities include:

• We could store a raw pointer, returned by ModuleRuntimeInfo, into Instance so we call the indirect function once at construction and then never again.
• The ModuleRuntimeInfo could perhaps return an Arc "package" of various other bits and pieces of information that don't need to go through a virtual lookup. Or otherwise we could do away with the ModuleRuntimeInfo trait and instead have some sort of structure there which is precomputed for each Module (this would be a large-ish refactoring).

And possibly other strategies as well. Given the relatively low impact of having this stored in each instance though this isn't the most pressing issue.

Wasmtime GitHub notifications bot (May 27 2022 at 18:22):

alexcrichton labeled issue #4191:

Currently whenever an instance is created Wasmtime will calculate the VMOffsets structure (also for the pooling allocator). This VMOffsets structure which is actually quite large is also stored within the Instance allocation for each instance. This means that every instantiation is redoing this work and additionally "wasting" space by storing this in each Instance. While the cost of computation here and the cost of initializing this storage is pretty small I think this would still be good to fix.

I think a better solution would be to perhaps store the VMOffsets in the runtime_info field since this information is statically known when the module is created and it can live in one location in the module and be referenced indirectly by each instance. The reason I hesitate to do this though is that accessing the vmoffsets would then become a dynamic function call (since ModuleRuntimeInfo is a trait). as opposed to today where information is at a static offset within Instance. I'm worried about the runtime impact of naively moving this information behind ModuleRuntimeInfo (since VMOffsets is pretty hot).

I'm not sure how best to solve this immediately, but some possibilities include:

• We could store a raw pointer, returned by ModuleRuntimeInfo, into Instance so we call the indirect function once at construction and then never again.
• The ModuleRuntimeInfo could perhaps return an Arc "package" of various other bits and pieces of information that don't need to go through a virtual lookup. Or otherwise we could do away with the ModuleRuntimeInfo trait and instead have some sort of structure there which is precomputed for each Module (this would be a large-ish refactoring).

And possibly other strategies as well. Given the relatively low impact of having this stored in each instance though this isn't the most pressing issue.

Wasmtime GitHub notifications bot (Dec 02 2022 at 00:10):

alexcrichton commented on issue #4191:

Done in https://github.com/bytecodealliance/wasmtime/pull/5346

Wasmtime GitHub notifications bot (Dec 02 2022 at 00:10):

alexcrichton closed issue #4191:

Currently whenever an instance is created Wasmtime will calculate the VMOffsets structure (also for the pooling allocator). This VMOffsets structure which is actually quite large is also stored within the Instance allocation for each instance. This means that every instantiation is redoing this work and additionally "wasting" space by storing this in each Instance. While the cost of computation here and the cost of initializing this storage is pretty small I think this would still be good to fix.

I think a better solution would be to perhaps store the VMOffsets in the runtime_info field since this information is statically known when the module is created and it can live in one location in the module and be referenced indirectly by each instance. The reason I hesitate to do this though is that accessing the vmoffsets would then become a dynamic function call (since ModuleRuntimeInfo is a trait). as opposed to today where information is at a static offset within Instance. I'm worried about the runtime impact of naively moving this information behind ModuleRuntimeInfo (since VMOffsets is pretty hot).

I'm not sure how best to solve this immediately, but some possibilities include:

• We could store a raw pointer, returned by ModuleRuntimeInfo, into Instance so we call the indirect function once at construction and then never again.
• The ModuleRuntimeInfo could perhaps return an Arc "package" of various other bits and pieces of information that don't need to go through a virtual lookup. Or otherwise we could do away with the ModuleRuntimeInfo trait and instead have some sort of structure there which is precomputed for each Module (this would be a large-ish refactoring).

And possibly other strategies as well. Given the relatively low impact of having this stored in each instance though this isn't the most pressing issue.

Last updated: Nov 22 2024 at 16:03 UTC