Skip to content

Remove hash tables and bump chunk from the DRC collector #11175

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Jul 2, 2025

This removes the explicit HashSets used to represent the over-approximated-stack-roots and precise-stack-roots sets and replaces them with an intrusive, singly-linked list and a mark bit in the object headers respectively. The new list implementation also subsumes the old bump chunk that sat in front of the old over-approximated-stack-roots hash set.

This shaves off about 25% of the time it takes to run the test case in #11141 for me locally.

This also ended up being a nice simplification of the DRC collector, which in turn allowed us to further simplify the GcHeap trait, since we no longer ever need to GC before passing GC refs into Wasm.

Fixes #11162

@fitzgen fitzgen requested review from a team as code owners July 2, 2025 20:09
@fitzgen fitzgen requested review from cfallin and alexcrichton and removed request for a team July 2, 2025 20:09
This removes the explicit `HashSet`s used to represent the
over-approximated-stack-roots and precise-stack-roots sets and replaces them
with an intrusive, singly-linked list and a mark bit in the object headers
respectively. The new list implementation also subsumes the old bump chunk that
sat in front of the old over-approximated-stack-roots hash set.

This shaves off about 25% of the time it takes to run the test case in
bytecodealliance#11141 for me locally.

This also ended up being a nice simplification of the DRC collector, which in
turn allowed us to further simplify the `GcHeap` trait, since we no longer ever
need to GC before passing GC refs into Wasm.

Fixes bytecodealliance#11162
@fitzgen fitzgen force-pushed the issue-11162-no-hash-sets-in-drc branch from 898354f to da36faf Compare July 2, 2025 20:09
);
self.kind &= VMGcKind::MASK;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was such a silly bug but it made me feel like I was losing my mind 🤦

Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks generally good to me -- nice speedups too! Just a few thoughts below.

stack-roots list and decrementing its ref count"
);
next = header.next_over_approximated_stack_root();
let prev_next = header.next_over_approximated_stack_root();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I see why we load this value twice -- can we use next below when we patch the prev link?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VMGcRef doesn't implement Clone since cloning a VMGcRef potentially needs to run barriers, so we have dedicated methods to clone with those barriers if necessary. However, inside the GC implementation that isn't really a concern so we have unchecked_copy for these cases that don't need barriers. That said, when the GC ref is wrapped in an Option like it is here, it can be a bit of a mouthful, and we would have to do next.as_ref().map(|r| r.unchecked_copy()). So I figured I'd just grab it from the header twice and let LLVM clean things up.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really like how this worked out, especially how it simplifies passing GC references into wasm

@fitzgen fitzgen enabled auto-merge July 2, 2025 22:30
@fitzgen fitzgen added this pull request to the merge queue Jul 2, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 2, 2025
@github-actions github-actions bot added wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:ref-types Issues related to reference types and GC in Wasmtime labels Jul 3, 2025
Copy link

github-actions bot commented Jul 3, 2025

Subscribe to Label Action

cc @fitzgen

This issue or pull request has been labeled: "wasmtime:api", "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 .github/subscribe-to-label.json configuration file.

Learn more.

@fitzgen fitzgen enabled auto-merge July 3, 2025 15:29
@fitzgen fitzgen added this pull request to the merge queue Jul 3, 2025
Merged via the queue into bytecodealliance:main with commit 58e295e Jul 3, 2025
42 checks passed
@fitzgen fitzgen deleted the issue-11162-no-hash-sets-in-drc branch July 3, 2025 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:ref-types Issues related to reference types and GC in Wasmtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove hash sets and bump chunk from DRC collector
3 participants