Stream: git-wasmtime

Topic: wasmtime / issue #9347 Speed up getting and setting funcr...

Wasmtime GitHub notifications bot (Oct 01 2024 at 16:39):

fitzgen added the performance label to Issue #9347.

Wasmtime GitHub notifications bot (Oct 01 2024 at 16:39):

fitzgen added the cranelift:goal:optimize-speed label to Issue #9347.

Wasmtime GitHub notifications bot (Oct 01 2024 at 16:39):

fitzgen added the wasmtime:ref-types label to Issue #9347.

Wasmtime GitHub notifications bot (Oct 01 2024 at 16:39):

fitzgen opened issue #9347:

We don't keep VMFuncRef pointers inside the GC heap, as the GC heap is untrusted, and instead have a side table, and store table IDs in GC objects. We currently use libcalls to do id-to-funcref conversion when reading a funcref out from a GC object and to intern a funcref and get its associated table ID when writing the funcref into a GC object. libcalls on field/element access are very much not ideal from a performance perspective.

I wrote up some thoughts on how we could improve the situation in the original PR:

My most-immediate thoughts are that we would do roughly the following to speed this up:

• Expose the slab to Wasm, allowing id-to-funcref conversion to happen fully within wasm code
• for funcref-to-id conversion, add an LRU/associative cache to the vmctx (or maybe runtime limits) to cache the results of the libcall and allow the happy path to stay within wasm code. the slow path would still fall back to a libcall however (I do not want to implement hashing in wasm code and try to keep it in sync with the Rust hashing)

My hope is that the above would result in good enough perf for us to not have to revisit this for quite a while.

_Originally posted by @fitzgen in https://github.com/bytecodealliance/wasmtime/issues/9341#issuecomment-2386456719_

Wasmtime GitHub notifications bot (Oct 01 2024 at 16:40):

github-actions[bot] commented on issue #9347:

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 <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Oct 09 2024 at 23:48):

fitzgen commented on issue #9347:

@cfallin and I were just brainstorming on this problem and came up with a couple interesting ideas.

Idea 1

• all VMFuncRefs inside a store are allocated within an arena in that store. all VMFuncRefs for the store, so instead of putting an module's funcrefs in the instance's vmctx, they would be allocated into this arena.
• now we can use raw *mut VMFuncRefs inside the GC heap, without trusting the GC heap, by bounds checking that the pointer is within that arena and appropriately aligned on every field/element read from a GC object

The tricky part is that this arena can't be resized or else existing pointers are invalidated. So we would have to rely on pre-allocating (virtual) memory, and not allow passing new, dynamically-created wasmtime::Funcs to Wasm beyond that pre-allocated limit.

Idea 2

Expose the id-to-funcref slab to Wasm, as described above. (Potentially not useing wasmtime::Slab anymore, but instead some simpler type that is more easily exposed to Wasm code.)

But instead of worrying about interning and/or wasting space and/or doing GC to clean up unused entries, we do the following:

• add an id: Option<FuncRefId> field to VMFuncRef
• when doing funcref-to-id conversion:
  • if (*funcref).id is some, then we reuse the existing id
  • otherwise, when it is none, we do a libcall to push the funcref into the side table (or just push onto the slab directly in Wasm code) and set the id field to the new entry's index

Last updated: Dec 23 2024 at 12:05 UTC