winch: drc barriers by macovedj · Pull Request #14081 · bytecodealliance/wasmtime

macovedj · 2026-08-05T17:39:34Z

Continues the work tracked in #14057 by adding DRC barriers for GC references in Winch. This unblocks exception-handling support work in Winch.
Closes #14057.

Step 2 of the barrier plan: all of the spec's memory traffic, none of its branches. Knowingly wrong for null until the guards land; the disas test is the oracle.

First of the two step-3 guards; the decrement guard is next.

Completes the write barrier's null guards; a global.set of ref.null touches no refcount on either side.

Completes the write barrier: the decremented count is only written back on the nonzero path, matching the cranelift DRC barrier; at zero the old value goes to the drop_gc_ref builtin in a cold block. The call gets a stack map like any other.

Proven load-bearing: with the barrier arm disabled the object is freed while the global still holds it (premature free), failing the first assertion.

Winch's barriers reference these constants unconditionally, so move them to the always-compiled gc module and make TRAP_GC_HEAP_CORRUPT public for the barrier bounds checks.

Adds the read barrier for global.get: references loaded onto the stack are enrolled in the over-approximated stack-roots list so a collection cannot free them out from under the frame that loaded them, forcing a GC when the list outgrows its threshold. The loaded reference is homed into its stack slot first so the force-gc call's stack map covers it. Both barriers now trap GC_HEAP_CORRUPT if an object's DRC header would extend past the GC heap's current length before any header access, matching Cranelift's prepare_gc_ref_access. Read-barrier test proven load-bearing under gc_zeal.

saulecabrera · 2026-08-05T19:00:12Z

Happy to take this one as well @alexcrichton.

github-actions · 2026-08-05T20:13:18Z

Subscribe to Label Action

cc @saulecabrera

Details

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config", "wasmtime:docs", "winch"

Thus the following users have been cc'd because of the following labels:

saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

github-actions · 2026-08-05T21:04:50Z

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:

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.

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 (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 for more 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.

Details

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

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

Learn more.

alexcrichton · 2026-08-10T14:29:47Z

cc @fitzgen on this as well as you're likely curious

In talking briefly about this in-person at the CG meeting last week, one possibility as well could be that the DRC collector may not be supported by Winch and instead only the copying/null collectors are supported which don't need barriers. Unless you've got a specific need for DRC @macovedj it seems ok to me if Winch only supports a subset of the GC collectors (notably the main one though, the copying collector). Although having hooks for barriers is always a pretty nice thing since it makes adding/refactoring in the future easier since the barriers are already outlined. Mostly just wanted to throw this out there that I don't personally think DRC is required in Winch to turn GC/exceptions on for Winch in the long-run.

macovedj · 2026-08-10T15:39:52Z

cc @fitzgen on this as well as you're likely curious

In talking briefly about this in-person at the CG meeting last week, one possibility as well could be that the DRC collector may not be supported by Winch and instead only the copying/null collectors are supported which don't need barriers. Unless you've got a specific need for DRC @macovedj it seems ok to me if Winch only supports a subset of the GC collectors (notably the main one though, the copying collector). Although having hooks for barriers is always a pretty nice thing since it makes adding/refactoring in the future easier since the barriers are already outlined. Mostly just wanted to throw this out there that I don't personally think DRC is required in Winch to turn GC/exceptions on for Winch in the long-run.

Oh interesting. I don't have a strong need, and I think that not adding it would simplify the EH work ahead for winch. That said, I talked with @saulecabrera a bit offline and got the impression that this isn't that far from landing and that winch benefits from the cranelift parity. Happy to drop the PR if anybody has concerns, but also happy to keep moving it forward if the DRC support is attractive to everybody.

saulecabrera · 2026-08-10T16:03:45Z

@alexcrichton I agree that this is not required to land GC and EH. However, sometimes I find it a bit difficult to draw the line on when a compiler (Winch in my case) should support or not certain engine features. My assumption until now has been that Winch should try to provide as much parity as possible with Cranelift, unless there's a real technical reason not to (e.g., supporting function inlining). In this case parity seemed the right default to me; but also we can decide not to land it if there are any specific concerns.

alexcrichton · 2026-08-11T14:36:59Z

No yeah that all sounds reasonable to me. If it's significantly complicated for Winch to support something I personally think it's always in the cards to avoid implementing it, but that's not the case here so seems totally fine to land

saulecabrera

LGTM, thanks!

macovedj added 9 commits August 5, 2026 12:29

winch: gc barrier predicate; un-gate DRC for development

fde76b8

winch: straight-line DRC write barrier in global.set

5a78fd5

Step 2 of the barrier plan: all of the spec's memory traffic, none of its branches. Knowingly wrong for null until the guards land; the disas test is the oracle.

winch: null guard around the write barrier increment

e90a8ab

First of the two step-3 guards; the decrement guard is next.

winch: null guard around the write barrier decrement

bb4020a

Completes the write barrier's null guards; a global.set of ref.null touches no refcount on either side.

winch: observe the write barrier dropping the last reference

e5e8721

Proven load-bearing: with the barrier arm disabled the object is freed while the global still holds it (premature free), failing the first assertion.

environ: expose DRC header constants without the gc-drc feature

c6d3d95

Winch's barriers reference these constants unconditionally, so move them to the always-compiled gc module and make TRAP_GC_HEAP_CORRUPT public for the barrier bounds checks.

winch: complete DRC global barrier coverage

ee3a463

macovedj requested review from a team as code owners August 5, 2026 17:39

macovedj requested review from alexcrichton and removed request for a team August 5, 2026 17:39

saulecabrera requested review from saulecabrera and removed request for a team and alexcrichton August 5, 2026 19:00

github-actions Bot added wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:config Issues related to the configuration of Wasmtime wasmtime:docs Issues related to Wasmtime's documentation winch Winch issues or pull requests labels Aug 5, 2026

saulecabrera reviewed Aug 7, 2026

View reviewed changes

Comment thread crates/environ/src/gc.rs Outdated

Comment thread winch/codegen/src/visitor.rs

improve readability and reusability

dd0f39e

saulecabrera reviewed Aug 10, 2026

View reviewed changes

Comment thread winch/codegen/src/codegen/drc.rs

improve register usage

e553862

saulecabrera approved these changes Aug 12, 2026

View reviewed changes

saulecabrera added this pull request to the merge queue Aug 12, 2026

Merged via the queue into bytecodealliance:main with commit f08de39 Aug 12, 2026
53 checks passed

Navigation Menu

Uh oh!

winch: drc barriers - #14081

winch: drc barriers#14081
saulecabrera merged 11 commits into
bytecodealliance:mainfrom
macovedj:winch-drc-barriers

macovedj commented Aug 5, 2026

Uh oh!

saulecabrera commented Aug 5, 2026

Uh oh!

github-actions Bot commented Aug 5, 2026

Uh oh!

github-actions Bot commented Aug 5, 2026

Uh oh!

Uh oh!

Uh oh!

alexcrichton commented Aug 10, 2026

Uh oh!

macovedj commented Aug 10, 2026

Uh oh!

Uh oh!

saulecabrera commented Aug 10, 2026 •

edited

Loading

Uh oh!

alexcrichton commented Aug 11, 2026

Uh oh!

saulecabrera left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

macovedj commented Aug 5, 2026

Uh oh!

saulecabrera commented Aug 5, 2026

Uh oh!

github-actions Bot commented Aug 5, 2026

Subscribe to Label Action

Uh oh!

github-actions Bot commented Aug 5, 2026

Label Messager: wasmtime:config

Uh oh!

Uh oh!

Uh oh!

alexcrichton commented Aug 10, 2026

Uh oh!

macovedj commented Aug 10, 2026

Uh oh!

Uh oh!

saulecabrera commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexcrichton commented Aug 11, 2026

Uh oh!

saulecabrera left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

saulecabrera commented Aug 10, 2026 •

edited

Loading