wasmtime / PR #13822 Gc performance improvements, in part... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #13822 Gc performance improvements, in part...

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:14):

tschneidereit requested fitzgen for a review on PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:14):

tschneidereit requested wasmtime-core-reviewers for a review on PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:14):

tschneidereit opened PR #13822 from tschneidereit:gc-perf-improvements to bytecodealliance:main:

This is a set of commits which, combined, substantially improve GC performance, at least as measured for one mid-sized Kotlin component I've been testing. (Which I unfortunately can't share.)

While single-threaded performance improves substantially with the first commit, the other two only make a real difference when running multiple instances in parallel. In total, performance for 20 concurrent requests improves from 168 RPS to 17680 RPS:

rev concurrency=1 concurrency=20

main 239 168

initial-heap-size=2MB 1549 1809

batched-trace-info 1565 4050

cached-subtype-checks 1610 17681

rev	concurrency=1	concurrency=20
`main`	239	168
initial-heap-size=2MB	1549	1809
batched-trace-info	1565	4050
cached-subtype-checks	1610	17681

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:15):

tschneidereit commented on PR #13822:

One thing I'm wondering is if we should choose a different default for the initial GC heap size allocation. Perhaps we should set that to at least one wasm page?

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:17):

tschneidereit updated PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:27):

tschneidereit commented on PR #13822:

One thing I'm wondering is if we should choose a different default for the initial GC heap size allocation. Perhaps we should set that to at least one wasm page?

Testing this just now, it doesn't seem to really make much of a difference. Which I guess makes some sense: setting the initial size to 64kb will only ever remove the first, cheapest growth cycle.

Wasmtime GitHub notifications bot (Jul 06 2026 at 14:48):

tschneidereit updated PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:43):

:memo: alexcrichton submitted PR review:

Overall this looks pretty reasonable to me, and are definitely levers that were expected to be slow points about the GC implementation (primarily all the locking).

Personally I'd like to ideally consider completely redesigning how TraceInfo is managed (the second commit here). To me this seems like something we should precompute at module-creation-time and not require any locks at all during instantiation/runtime. As-is that's not going to be an easy refactor, however.

I also think that this is something where we're going to need to bust out unsafe and raw pointers. For example what I'm thinking is that Modules (and RegisteredTypes) should have TraceInfo precomputed along with a map from VMSharedTypeIndex to this information. When instantiating within a store this shouldn't require cloning TraceInfo because that'll just slow down instantiation, especially when there are a lot of types. The module/RegisteredType is already strong-held by the store as well, so using more Arcs is also extra overhead (e.g. cloning a contended Arc is not the cheapest).

Basically the second commit here I'd like to ideally separate out and take some time to figure out what we "really want to do" w.r.t. performance there.

The third commit I think is another in this category, but the true fix is something we know about and is also pretty gnarly. As a temporary fix for performance the hash-map-cache seems reasonable.

So, tl;dr; I think it's fine to land the 1st/3rd commits here with light modifications, but I'd prefer to take more time to figure out what to do about the 2nd commit.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:43):

:speech_balloon: alexcrichton created PR review comment:

Would it be possible to model ensure_trace_info as a wrapper around this function instead of the other way around? That way implementations are guaranteed to, by default, implement the bulk registration.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:43):

:speech_balloon: alexcrichton created PR review comment:

I think this'd be best stored in Tunables so gc_heap_memory_type() could also be updated as-is to return a memory with the appropriate minimum set. Implementation/feature-wise this all looks fine though, so just shuffling around where this is defined.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:43):

:speech_balloon: alexcrichton created PR review comment:

Could this use NopHasher we have elsewhere perhaps?

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:25):

:memo: fitzgen submitted PR review:

Thanks! A few requested tweaks.

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:25):

:speech_balloon: fitzgen created PR review comment:

Can we store this in the tunables, where we store the other similar knobs for memories and the GC heap?

Also, what happens if the gc_heap_initial_size is larger than the gc_heap_reservation? It seems like maybe we actually just want to always make this be round_down(gc_heap_reservation, DEFAULT_WASM_PAGE_SIZE) and adjust the Tunables::gc_heap_memory_type method to have its initial/min size reflect that reservation size. This would, I think, give us the wins this commit is aiming for without adding a new / partially redundant config knob.

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:25):

:speech_balloon: fitzgen created PR review comment:

As an additional potential follow up: we could probably make this register even fewer trace infos by making it so that if the collector keeps small trace infos inline in the GC header (which the copying collector does) then we don't actually register that type in the TraceInfos registry. Would need a little API design work since different collectors do/don't store tracing data inline the GC header, and theoretically they could also have different capacity for the size of trace info data that can be stored inline in the header. But it is worth looking into.

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:25):

:speech_balloon: fitzgen created PR review comment:

Could we factor this cache out into its own type to try and encapsulate some of the details from the rest of the StoreOpaque (which is massive, and I don't want to keep making it more massive), something like this:
// is_subtype_cache.rs

pub(crate) struct IsSubtypeCache {
    cache: crate::hash_map::HashMap<u64, bool, GcTypeCacheHasher>,
}

impl IsSubtypeCache {
    pub(crate) fn is_subtype(&mut self, engine: &Engine, sub: VMSharedTypeIndex, sup: VMSharedTypeIndex) -> bool {
         // ...
    }
}

// store.rs

impl StoreOpaque {
    pub fn is_subtype(&mut self, sub: VMSharedTypeIndex, sup: VMSharedTypeIndex) -> bool {
        self.is_subtype_cache.is_subtype(&self.engine, sub, sup)
    }
}
Also, do we want this to cache's size to grow unbounded? Maybe we want to use an LRU cache like https://docs.rs/associative-cache/latest/associative_cache/ instead?

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:25):

:speech_balloon: fitzgen created PR review comment:

Also, if we do end up keeping this new config knob, we want to also hook it up to our fuzz config in crates/fuzzing/src/generators/config.rs

Wasmtime GitHub notifications bot (Jul 06 2026 at 18:22):

github-actions[bot] added the label wasmtime:api on PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 18:22):

github-actions[bot] added the label wasmtime:config on PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 18:22):

github-actions[bot] added the label wasmtime:ref-types on PR #13822.

Wasmtime GitHub notifications bot (Jul 06 2026 at 18:23):

github-actions[bot] commented on PR #13822:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config", "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 (Jul 06 2026 at 19:18):

github-actions[bot] commented on PR #13822:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

[ ] If you added a new Config method, you wrote extensive documentation for
it.

<details>

Our documentation should be of the following form:

```text
Short, simple summary sentence.

More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.

Is this method fallible? If so, when can it return an error?

Can this method panic? If so, when does it panic?

Example

Optional example here.
```

</details>

[ ] If you added a new Config method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.

<details>

For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.

Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nested structs).

Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

</details>

[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Jul 06 2026 at 21:15):

fitzgen commented on PR #13822:

Also I'd be curious whether you saw/see any perf improvements on Sightglass's GC benchmarks:

https://github.com/bytecodealliance/sightglass/tree/main/benchmarks/kotlin-richards

https://github.com/bytecodealliance/sightglass/tree/main/benchmarks/splay