Stream: git-wasmtime

Topic: wasmtime / issue #11164 DRC collector should store trace ...

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:17):

fitzgen opened issue #11164:

Right now, we have a hash map from VMSharedTypeIndex to metadata about how to trace objects of that type:

https://github.com/bytecodealliance/wasmtime/blob/57ba95e92eff1d02f6b05ab86b9e81b35bd69d28/crates/wasmtime/src/runtime/vm/gc/enabled/drc.rs#L115-L116

This map is lazily updated as we allocate objects, inserting entries whenever we allocate an object of a type we haven't allocated before:

https://github.com/bytecodealliance/wasmtime/blob/57ba95e92eff1d02f6b05ab86b9e81b35bd69d28/crates/wasmtime/src/runtime/vm/gc/enabled/drc.rs#L259-L297

This system is slow:

1. We always have to hash stuff on the hot allocation path, even if we already have that allocation's type's trace info.
2. When we have to add a new entry because it is the first allocation of a given type, we hit the engine's type registry, which requires acquiring a read-lock.

We could address (1) by adding a one-item cache in front of the hashing, but that isn't super satisfactory.

Better would be to completely remove the need for this type-to-trace-info map in the first place by inlining the metadata we need to trace an object inline into its header:

• For arrays, this is just a bit saying whether the elements are GC refs or not.
• For structs, this is a bitmap:
  • the ith bit represents whether object_ptr + FIELDS_OFFSET + (i * size_of(VMGcRef)) is a VMGcRef field that needs to be traced or not

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:17):

fitzgen added the performance label to Issue #11164.

Wasmtime GitHub notifications bot (Jun 30 2025 at 20:17):

fitzgen added the wasm-proposal:gc label to Issue #11164.

Last updated: Dec 06 2025 at 06:05 UTC