Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51): Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51):fitzgen requested alexcrichton for a review on PR #12921.
Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51):fitzgen opened PR #12921 from fitzgen:add-gc-zeal-infra to bytecodealliance:main:
This initial commit just sets up the initial GC Zeal infrastructure, it doesn't actually start using it anywhere yet.
- Adds support for
cfg(gc_zeal)tocrates/wasmtime/build.rsandcrates/cranelift/build.rs- Defines
gc_assert!macro- Defines
wasmtime_environ::gc::POISONconstant for GC heap poisoning- Adds debug assert that
POISONdoesn't overlap any validVMGcKinddiscriminant- Adds CI job to run GC-related tests with
cfg(gc_zeal)<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51):fitzgen requested wasmtime-compiler-reviewers for a review on PR #12921.
Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51):fitzgen requested wasmtime-core-reviewers for a review on PR #12921.
Wasmtime GitHub notifications bot (Mar 31 2026 at 23:51):fitzgen requested wasmtime-default-reviewers for a review on PR #12921.
Wasmtime GitHub notifications bot (Apr 01 2026 at 01:09):github-actions[bot] added the label wasmtime:api on PR #12921.
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton submitted PR review:
I'm not personally too familiar with the "GC Zeal" mode from SpiderMonkey (where I think you're drawing inspiration from right?). Could you detail a bit more how this is going to be used and what it would mean? Is this worth perhaps documenting somewhere?
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
Would using something with a more "random" bit pattern make sense here perhaps? I'd imagine that'd be much less likely to happen naturally as opposed to paving over with -1 accidentally aligning with this poison value. I don't mean true random but basically go run
random::<u8>()and then hardcode that here.
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
I'm not familiar with "gc zeal" in the spidermonkey sense so I don't have a great intuition here, but what's the benefit of this over
debug_assert!?
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
This'll probably want an
if: ...to only run on the full test suite run to avoid running on PRs by default
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
You'll want to add this to the "join node" at the bottom of this file to ensure failure here blocks PRs/merging.
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
Personally I prefer to keep CI logic as simple as possible to make it easier to reproduce locally, could this all be codified in the
tests/wast.rsfile instead of in bash here? Something like a special env var which says "do this logic instead" or something like that which switches how the test is run
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
Instead of using a build script this can be specified declaratively here
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
Where possible, mind avoiding using
#[cfg]? Here I think it'd be fine to just omit this since this looks fully const-propagatable.
Wasmtime GitHub notifications bot (Apr 01 2026 at 13:05):alexcrichton created PR review comment:
Also, in terms of implementation, could this be
($($t:tt)*)) => { if cfg!(gc_zeal) { assert!($($t)*); } }? basically just wrap the syntax ofassert!without specifying multiple arms
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:10):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:10):fitzgen created PR review comment:
Oh nice, I missed that that was a thing
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:12):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:12):fitzgen created PR review comment:
I'm not familiar with "gc zeal" in the spidermonkey sense so I don't have a great intuition here, but what's the benefit of this over
debug_assert!?These checks are too expensive for
debug_assert!s. I wouldn't want to enable them for anyone doing debug builds which embed wasmtime, for example. They are really there only for fuzzing and/or when debugging GC heap corruption and such.
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:37):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:37):fitzgen created PR review comment:
I wanted it to be a recognizable pattern when staring at things in
gdb. Changed it to0b00001111, which is still recognizable but less likely to accidentally conflict with other stuff.
Wasmtime GitHub notifications bot (Apr 01 2026 at 18:41):fitzgen updated PR #12921.
Wasmtime GitHub notifications bot (Apr 01 2026 at 19:58):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 01 2026 at 20:08):fitzgen added PR #12921 Add "GC Zeal" infrastructure for additional, aggressive GC assertions to the merge queue.
Wasmtime GitHub notifications bot (Apr 01 2026 at 20:56):fitzgen merged PR #12921.
Wasmtime GitHub notifications bot (Apr 01 2026 at 20:56):fitzgen removed PR #12921 Add "GC Zeal" infrastructure for additional, aggressive GC assertions from the merge queue.
Last updated: Apr 12 2026 at 23:10 UTC