Stream: git-wasmtime

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


view this post on Zulip 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:

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.

view this post on Zulip 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:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 02 2022 at 00:10):

alexcrichton commented on issue #4191:

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

view this post on Zulip 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:

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: Dec 23 2024 at 12:05 UTC