bytecodealliance / bytecodealliance/wasmtime

DRC collector should store trace info inline in objects

Open
#11,164 0 comments 0 reactions 0 assignees View on GitHub
performance wasm-proposal:gc
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.