Skip to content

winch: drc barriers - #14081

Open
macovedj wants to merge 9 commits into
bytecodealliance:mainfrom
macovedj:winch-drc-barriers
Open

winch: drc barriers#14081
macovedj wants to merge 9 commits into
bytecodealliance:mainfrom
macovedj:winch-drc-barriers

Conversation

@macovedj

@macovedj macovedj commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

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.
@macovedj
macovedj requested review from a team as code owners August 5, 2026 17:39
@macovedj
macovedj requested review from alexcrichton and removed request for a team August 5, 2026 17:39
@saulecabrera

Copy link
Copy Markdown
Member

Happy to take this one as well @alexcrichton.

@saulecabrera
saulecabrera requested review from saulecabrera and removed request for a team and alexcrichton August 5, 2026 19:00
@github-actions 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
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown

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

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown

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.

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:config Issues related to the configuration of Wasmtime wasmtime:docs Issues related to Wasmtime's documentation winch Winch issues or pull requests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

winch: gc infra for exception handling support and future gc work

2 participants