bytecodealliance / bytecodealliance/wasmtime
DRC collector should store trace info inline in objects
- Dominant language
- Rust
- Stars
- 18.6k
- Forks
- 1.8k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 121
Description
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 `i`th bit represents whether `object_ptr + FIELDS_OFFSET + (i * size_of(VMGcRef))` is a `VMGcRef` field that needs to be traced or not
Contributor guide
Assessment
This issue has not been assessed yet.