wasmtime / PR #11284 Record and Replay Support for Compon... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #11284 Record and Replay Support for Compon...

Wasmtime GitHub notifications bot (Jul 18 2025 at 23:26):

arjunr2 opened PR #11284 from arjunr2:main to bytecodealliance:main:

Brief

This PR is intended to support deterministic record and replay (RR) of Wasm components intrinsically in Wasmtime, and received an initial round of discussion in the Wasmtime bi-weekly meeting on 07/18

Motivation

RR is a very useful primitive for improving the debugging story of Wasm in Wasmtime. Bugs that are often encountered in modules during deployment, can In particular, it provides the foundation for the following (to name a few):

Reverse-execution (a.k.a, time-travel) debugging

Offline static/dynamic analysis of modules

Profiling of module/runtime components

Automatic extraction of differential unit-tests for system interfaces (e.g. WASI)

Interposition points for targeted fuzzing of system interfaces and/or modules

Scope

This initial PR provides the base primitives for recording and replay events. It supports RR at all import function boundaries and lowering rules for component types. The RR event infrastructure is intended to be easily extensible to new event types as new use-cases emerge.

Primary Goals

Enabling low overhead (memory, compute, and trace size) recording and high-performance replay,

Full determinism during replay that can run outside the embedder context.

An engine-agnostic trace recording format -- the goal is to purely capture guest-host boundary crossings (import calls and component model interactions) that can be reasonably interpreted by another component model compliant engine.

Non-Goals (Subject to Discussion)

A human readable trace format. This belong better in something like wit-bindgen, and/or as an independent tool over the low-level trace

Replay support for updated versions of a recorded module -- this requires a much more coordinated effort from the producers as well to make this practically useful.

Initial Performance Numbers

Some initial runs on compression libraries like zstd show a 4-5% overhead on recording logic, excluding the disk I/O. This seems reasonable at the moment and likely doesn't need further optimization unless there are explicit use-cases.

Minor Todo

The following (minor) additions will be made in the coming days prior to potential merging:

Encoding hashes of modules in the recorded trace for validation

Generic writers/readers for RecordBuffer and ReplayBuffer

Questions for Maintainers

Do we get wasip1 for free by recording/replay at this level?

What's typically the most idiomatic way to serialize anyhow:Errors?

Wasmtime GitHub notifications bot (Jul 18 2025 at 23:26):

arjunr2 requested pchickey for a review on PR #11284.

Wasmtime GitHub notifications bot (Jul 18 2025 at 23:26):

arjunr2 requested wasmtime-core-reviewers for a review on PR #11284.

Wasmtime GitHub notifications bot (Jul 18 2025 at 23:35):

arjunr2 edited PR #11284:

Brief

This PR is intended to support deterministic record and replay (RR) of Wasm components intrinsically in Wasmtime, and received an initial round of discussion in the Wasmtime bi-weekly meeting on 07/17

Motivation

RR is a very useful primitive for improving the debugging story of Wasm in Wasmtime. Bugs that are often encountered in modules during deployment, can In particular, it provides the foundation for the following (to name a few):

Reverse-execution (a.k.a, time-travel) debugging

Offline static/dynamic analysis of modules

Profiling of module/runtime components

Automatic extraction of differential unit-tests for system interfaces (e.g. WASI)

Interposition points for targeted fuzzing of system interfaces and/or modules

Scope

This initial PR provides the base primitives for recording and replay events. It supports RR at all import function boundaries and lowering rules for component types. The RR event infrastructure is intended to be easily extensible to new event types as new use-cases emerge.

Primary Goals

Enabling low overhead (memory, compute, and trace size) recording and high-performance replay,

Full determinism during replay that can run outside the embedder context.

An engine-agnostic trace recording format -- the goal is to purely capture guest-host boundary crossings (import calls and component model interactions) that can be reasonably interpreted by another component model compliant engine.

Non-Goals (Subject to Discussion)

A human readable trace format. This belong better in something like wit-bindgen, and/or as an independent tool over the low-level trace

Replay support for updated versions of a recorded module -- this requires a much more coordinated effort from the producers as well to make this practically useful.

Initial Performance Numbers

Some initial runs on compression libraries like zstd show a 4-5% overhead on recording logic, excluding the disk I/O. This seems reasonable at the moment and likely doesn't need further optimization unless there are explicit use-cases.

Minor Todo

The following (minor) additions will be made in the coming days prior to potential merging:

Encoding hashes of modules in the recorded trace for validation

Generic writers/readers for RecordBuffer and ReplayBuffer

Questions for Maintainers

Do we get wasip1 for free by recording/replay at this level?

What's typically the most idiomatic way to serialize anyhow:Errors?

Wasmtime GitHub notifications bot (Jul 18 2025 at 23:35):

arjunr2 edited PR #11284:

Brief

This PR is intended to support deterministic record and replay (RR) of Wasm components intrinsically in Wasmtime, and received an initial round of discussion in the Wasmtime bi-weekly meeting on 07/17

Motivation

RR is a very useful primitive for improving the debugging story of Wasm in Wasmtime. Bugs that are often encountered in modules during deployment, can In particular, it provides the foundation for the following (to name a few):

Reverse-execution (a.k.a, time-travel) debugging

Offline static/dynamic analysis of modules

Profiling of module/runtime components

Automatic extraction of differential unit-tests for system interfaces (e.g. WASI)

Interposition points for targeted fuzzing of system interfaces and/or modules

Scope

This initial PR provides the base primitives for recording and replay events. It supports RR at all import function boundaries and lowering rules for component types. The RR event infrastructure is intended to be easily extensible to new event types as new use-cases emerge.

Primary Goals

Enabling low overhead (memory, compute, and trace size) recording and high-performance replay,

Full determinism during replay that can run outside the embedder context.

An engine-agnostic trace recording format -- the goal is to purely capture guest-host boundary crossings (import calls and component model interactions) that can be reasonably interpreted by another component model compliant engine.

Non-Goals (Subject to Discussion)

A human readable trace format. This belong better in something like wit-bindgen, and/or as an independent tool over the low-level trace

Replay support for updated versions of a recorded module -- this requires a much more coordinated effort from the producers as well to make this practically useful.

Initial Performance Numbers

Some initial runs on compression libraries like zstd show a 4-5% overhead on recording logic, excluding the disk I/O. This seems reasonable at the moment and likely doesn't need further optimization unless there are explicit use-cases.

Minor Todo

The following (minor) additions will be made in the coming days prior to potential merging:

Encoding hashes of modules in the recorded trace for validation

Generic writers/readers for RecordBuffer and ReplayBuffer

Feature gating all of RR

Questions for Maintainers

Do we get wasip1 for free by recording/replay at this level?

What's typically the most idiomatic way to serialize anyhow:Errors?

Wasmtime GitHub notifications bot (Jul 19 2025 at 02:25):

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

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 22 2025 at 21:32):

arjunr2 edited PR #11284:

Brief

This PR is intended to support deterministic record and replay (RR) of Wasm components intrinsically in Wasmtime, and received an initial round of discussion in the Wasmtime bi-weekly meeting on 07/17

Motivation

RR is a very useful primitive for improving the debugging story of Wasm in Wasmtime. Bugs that are often encountered in modules during deployment can be deterministically reproduced. In particular, it provides the foundation for the following (to name a few):

Reverse-execution (a.k.a, time-travel) debugging

Offline static/dynamic analysis of modules

Profiling of module/runtime components

Automatic extraction of differential unit-tests for system interfaces (e.g. WASI)

Interposition points for targeted fuzzing of system interfaces and/or modules

Scope

This initial PR provides the base primitives for recording and replay events. It supports RR at all import function boundaries and lowering rules for component types. The RR event infrastructure is intended to be easily extensible to new event types as new use-cases emerge.

Primary Goals

Enabling low overhead (memory, compute, and trace size) recording and high-performance replay,

Full determinism during replay that can run outside the embedder context.

An engine-agnostic trace recording format -- the goal is to purely capture guest-host boundary crossings (import calls and component model interactions) that can be reasonably interpreted by another component model compliant engine.

Non-Goals (Subject to Discussion)

A human readable trace format. This belong better in something like wit-bindgen, and/or as an independent tool over the low-level trace

Replay support for updated versions of a recorded module -- this requires a much more coordinated effort from the producers as well to make this practically useful.

Initial Performance Numbers

Some initial runs on compression libraries like zstd show a 4-5% overhead on recording logic, excluding the disk I/O. This seems reasonable at the moment and likely doesn't need further optimization unless there are explicit use-cases.

Minor Todo

The following (minor) additions will be made in the coming days prior to potential merging:

Encoding hashes of modules in the recorded trace for validation

Generic writers/readers for RecordBuffer and ReplayBuffer

Feature gating all of RR

Questions for Maintainers

Do we get wasip1 for free by recording/replay at this level?

What's typically the most idiomatic way to serialize anyhow:Errors?

Wasmtime GitHub notifications bot (Jul 22 2025 at 21:33):

arjunr2 edited PR #11284:

Brief

This PR is intended to support deterministic record and replay (RR) of Wasm components intrinsically in Wasmtime, and received an initial round of discussion in the Wasmtime bi-weekly meeting on 07/17

Motivation

RR is a very useful primitive for improving the debugging story of Wasm in Wasmtime. Bugs that are often encountered in modules during deployment can be deterministically reproduced. In particular, it provides the foundation for the following (to name a few):

Reverse-execution (a.k.a, time-travel) debugging

Offline static/dynamic analysis of prior module executions

Profiling of module/runtime components

Automatic extraction of differential unit-tests for system interfaces (e.g. WASI)

Interposition points for targeted fuzzing of system interfaces and/or modules

Scope

This initial PR provides the base primitives for recording and replay events. It supports RR at all import function boundaries and lowering rules for component types. The RR event infrastructure is intended to be easily extensible to new event types as new use-cases emerge.

Primary Goals

Enabling low overhead (memory, compute, and trace size) recording and high-performance replay,

Full determinism during replay that can run outside the embedder context.

An engine-agnostic trace recording format -- the goal is to purely capture guest-host boundary crossings (import calls and component model interactions) that can be reasonably interpreted by another component model compliant engine.

Non-Goals (Subject to Discussion)

A human readable trace format. This belong better in something like wit-bindgen, and/or as an independent tool over the low-level trace

Replay support for updated versions of a recorded module -- this requires a much more coordinated effort from the producers as well to make this practically useful.

Initial Performance Numbers

Some initial runs on compression libraries like zstd show a 4-5% overhead on recording logic, excluding the disk I/O. This seems reasonable at the moment and likely doesn't need further optimization unless there are explicit use-cases.

Minor Todo

The following (minor) additions will be made in the coming days prior to potential merging:

Encoding hashes of modules in the recorded trace for validation

Generic writers/readers for RecordBuffer and ReplayBuffer

Feature gating all of RR

Questions for Maintainers

Do we get wasip1 for free by recording/replay at this level?

What's typically the most idiomatic way to serialize anyhow:Errors?

Wasmtime GitHub notifications bot (Jul 24 2025 at 18:09):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 24 2025 at 18:39):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Let's put "required for faithful record/replay execution" as a new paragraph below this -- it's true and useful information, but it's secondary to what the option actually does.

Also, does "required" here mean that the user is required to configure it, or is it just describing a fact about this kind of configuration (and that is magically enabled some other way)?

(Sorry for writing nits here -- this becomes public documentation so we want to be very clear/unambiguous!)

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

If the above refactor (replay as a separate subcommand, without an option to itself record) doesn't pan out, separately we should always error if conflicting options are set here (that is, both record and replay together).

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

We should add more documention here: what is the macro for, how is it used, generally what does it expand to at a high level?

(It seems to dispatch to either adding a new event when recording, or advancing the trace and validating against it when replaying, right?)

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

I definitely appreciate the detailed feature-slicing here but I wonder if it might be a bit too much to be manageable internally -- perhaps we could have just rr and then rr-validate?

Also: have you measured the impact of validation checks that are always compiled in but disabled dynamically?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Rather than "repeal", I might say "disable"?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Rather than conditionalizing individual statements, generally what we try to do for this sort of thing is conditionalize on function definitions, and write alternate (often empty) ones -- this keeps the flow a bit cleaner inside bodies. So something like:
#[cfg(feature = "rr-type-validation")]
fn validate(...) { /* actually do it */ }

#[cfg(not(feature = "rr-type-validation"))]
fn validate(...) { /* nothing */ }
on event's impl, then always write if r.validate { event.validate(...); } here. This also avoids the awkward unused-variable warnings you're working around with the underscores here.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

I'd be curious which parts of our implementation depend on std -- I would suspect not too many, once we factor out the filesystem-based trace-writer? It might be nice to separate that part so we can do recording in no-std environments (e.g. embedded use-cases) too.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Does this break our no-std build? If we need std for something we should put the feature down in the feature dependencies below (std = [..., "postcard/use-std"]).

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Same comment here as above re: dispatching at a higher level.

In general, the sense I'm getting is that this sequence evolved out of a desire to keep the overall shape the same, and add hooks where needed. But it seems to me that there are basically three possible flows at a high level:

Normal host call;

Host call, recorded;

Replay of host call.

Could we instead write three different lower_results implementations depending on our mode, and dispatch once on the mode in call_host, to avoid the maze of fine-grained conditionals?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

High-level thoughts on command-line options:

It makes sense to me that record is a general option that the user should be able to set on any Wasmtime subcommand that executes WebAssembly; this includes wasmtime run, wasmtime serve, and maybe others. (Curious: have you tried it on an HTTP server component?)

However, replay is a specific and separate thing: for example, if I am replaying an HTTP server execution, I should not be spawning an actual HTTP server on the host side. Basically, the idea of replay is that it is replacing the "real" host with a trace, so it should be properly seen (I think) as a separate top-level driver.

With that in mind, what do you think about turning replay into a command, rather than an option?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

The "arrow syntax" here is a little too clever for my tastes at least -- it's not clear what is going on when I see that in the macro use-sites. I'd prefer the macro invocations to look as much like normal function calls as possible.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Just a hunch but after reading through this logic, I wonder: would it clean up the flow somewhat if we dispatched once on ReturnMode at the top level, then avoided all of the separate conditionals throughout the body? As-is, it's quite difficult to follow the different paths -- it seems somewhat decoupled and overly-abstracted.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

s/rr/record_replay/? Or better, separate enable_record() and enable_replay methods, each taking the data that goes into one arm of RRConfig?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

s/interleave/interleaved/

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

A thought: right now we have a RecordWriter that sinks trace content at the level of pre-serialized bytes (and hence we take a serializer as a dependency). Would it make sense to have a sink that instead consumes Rust-typed records, and is itself in charge of serializing them? That would let us build other sorts of interesting filtering external to Wasmtime; and would also mean that the trace reading and writing backends could be used as libraries for tooling. It would push a std dependence out of the core, too.

We could still provide fast default serialization/deserialization methods if we wanted (Record::to_bytes() / Record::from_bytes() or similar).

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

And in general actually, it might be good to have an explanatory comment here about record/replay hook points and what the sequences are, and how you're using macros to generalize over all of those.

Something like:

The sorts of events that need to be recorded and/or validated (e.g. write out a call sequence and note each point in the sequence)

Somehow describe strategy here: you have two main macros that are invoked at the start and end of a host-function call, and a few different kinds of wrappers to record the important values within that span.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Also, in general, we should make this optional = true and then enable the postcard dep itself when rr feature(s) are turned on below.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

check_determinism sounds like it could be enabling some option on the runtime config -- usually for bool predicates we say is_*, so perhaps is_determinism_enforced()?

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Is this "metadata" or is "config" a better name for it? Ordinarily I'd expect "metadata" to have something to do with the actual recorded content ("meta" to the "data"), e.g., module versions or something.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

I like to avoid transmute whenever possible, as it is so easy to get wrong; could we instead add a member to the union that is the size of the whole union (e.g., 128 bits) and read out the content that way? It is still unsafe (because it's a union) but is a whole lot more constrained.

Alternately, if you have to use transmute, an idiom we have in a bunch of places is transmute::<From, To>(...), i.e., explicitly write out the types so we can be sure we're casting what we think we are (and not, e.g., accidentally casting a pointer itself rather than the contents at that pointer).

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin submitted PR review:

Initial review -- this is looking really good overall!

My main high-level thought around the heart of the record/replay (the interaction with the component hostcall logic and lifting/lowering): there are a lot of fine-grained conditionals, and it's somewhat hard to trace, even though there are only three modes (running + recording, replaying, or just running). It feels like somehow we should be able to hoist the conditionals a bit more and then have straight-line sequences for each of those modes.

A few other misc thoughts:

We'll want to make sure we either plug all soundness holes or document them for the initial landing. We already know about component builtins (and their memory effects); we should ask around to ensure we catch any others.

For core-wasm recording, I suspect we'll want to validate that there are no exported memories or tables.

We should validate that the module is exactly the same on replay as on record -- I know you're working on adding hashing for this.

Some comments below about std dependence -- we should ensure the core can work, serializing into memory, in a no-std build.

We'll want at least @alexcrichton to give this a review as well, maybe after we try some of the refactors mentioned here.

Thanks again!

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

It seems that the _if part of this combinator is mainly used to conditionalize running the closure on add_validation. Would it make sense to instead have record_event and record_event_validation entry points, or perhaps even just wrap the relevant callsites in if r.add_validation { store.record_event(...); }? In general I'm wary of complex type-generic closure-taking helpers like this unless they pay their way to a significant degree.

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

Can we add a doc-comment here describing why we need a separate Replay return-mode? (Basically, the effects of the return are handled by replaying the trace instead, right?)

Wasmtime GitHub notifications bot (Jul 24 2025 at 22:42):

cfallin created PR review comment:

style nit: we end doc-comments with periods so s/module/module./. Likewise for the rest of the doc-comments in this diff (I see a few instances below too).

Wasmtime GitHub notifications bot (Jul 24 2025 at 23:18):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 24 2025 at 23:18):

arjunr2 requested wasmtime-default-reviewers for a review on PR #11284.

Wasmtime GitHub notifications bot (Jul 25 2025 at 00:48):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 25 2025 at 18:08):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 25 2025 at 18:21):

alexcrichton commented on PR #11284:

We'll want at least @alexcrichton to give this a review as well, maybe after we try some of the refactors mentioned here.

Happy to help out! (and agreed I'd like to once-over at some point)

How about scheduling a call when y'all are ready with the 3 of us? That'd probably be best to draw attention to any various areas and for me to ask some questoins in a high-bandwidth way before going off to review on my own.

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen submitted PR review:

Super excited for this!

I think we should adjust the #[cfg(...)] options / cargo features a little bit. Instead of having a cfg feature for just type validation, but always including the general record-replay code in the build, I think we should have a #[cfg(feature = "rr")] cargo feature for controlling whether we are building in the ability to do any kind of record-replay at all. (We don't want to force the smallest embedded builds of Wasmtime to include record-replay infrastructure, for example.) And then, when record-replay support was included at compile time, we can have runtime boolean knobs for whether to do type validation and divergence-checking when replaying.

Finally, in order to make it so that the whole core runtime isn't littered with #[cfg(feature = "rr")], we can do something similar to what we do with #[cfg(feature = "gc")] and the wasmtime::runtime::gc submodule:
// crates/wasmtime/src/runtime/rr.rs

#[cfg(feature = "rr")]
mod enabled;
#[cfg(feature = "rr")]
pub use enabled::*;

#[cfg(not(feature = "rr"))]
mod disabled;
#[cfg(not(feature = "rr"))]
pub use disabled::*;
The wasmtime::runtime::rr::enabled submodule would have the actual record-replay implementation, and the wasmtime::runtime::rr::disabled submodule would have a stubbed out version of the same public API but without constructors and with every public type being a newtype of wasmtime::runtime::uninhabited::Uninhabited. This pattern lets the core runtime usage of record-replay APIs look the same regardless whether we actually build in the code to do record-replay.

The other thing I think we need before this can land is some kind of testing or fuzzing story. At minimum, we should (1) make it so that the fuzzer can turn on recording during our existing fuzzing, and (2) we should have a smoke test that records some kind of Wasm program and then replays it back again and asserts that we get the same result again. As a follow up, I think we should also generalize that smoke test into a new fuzz target where we take an arbitrary Wasm module generated by the fuzzer, record its execution, and then replay that execution and assert that we get the same results (we can mostly rely on enabling the internal type validation and divergence checks for these assertions).

Let me know if any of this isn't clear or if I've overlooked something.

Thanks!

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

I'll go a step further than @cfallin did regarding the macros: I don't think that they are paying for themselves at all. I think we could use regular function calls and get very close to the macros in brevity, but end up with something much easier to understand for readers:
    cx.0.host_func_entry_event(storage, &types[ty.params])?;
And if we are concerned about the overhead of indexing into types here even when we aren't recording, then we could pass types and ty.params as two different arguments and the method would only index when recording was enabled. (Either way, we would probably want to mark the method as #[inline].)

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

Nitpick: the let _ = shouldn't be necessary here (you may also need to remove the semicolon at the end of the match).

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

This should be #[expect(unused_imports, reason = "<description of why>")] so that when we fix the warning, the missing warning becomes a warning itself, so that we don't forget to remove the allow.

If it is only unused in some cfgs, then we want to either #[cfg(...)] the imports appropriately, or use #[cfg_attr(expect(unused_imports, reason = "..."))]. In some scenarios one or the other makes more sense.

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

I don't think this is sound. Instead, I think we'll want something like this:

union SerializedValRaw {
    bytes: ValRawBytes,
    val: ValRaw,
}

impl SerializedValRaw {
    pub fn new(val: ValRaw) -> Self {
        // Zero-initialize `self.bytes` to ensure that there are
        // no undefined bytes in `self` and we don't ever try to
        // read and serialize undefined data.
        let ret = Self {
            // SAFETY: it is safe to zero-initialize `u8` arrays.
            bytes: unsafe { mem::zeroed() },
        };
        ret.val = val;
        ret
    }

    pub fn get_val(&self) -> ValRaw {
        // SAFETY: `self` is always initialized in `new` such
        // that there is a valid `ValRaw` inside.
        unsafe { self.val }
    }

    pub fn get_bytes(&self) -> ValRawBytes {
        // SAFETY: We take care to ensure that `self` has no
        // undefined bytes in the constructor, so accessing the
        // raw bytes representation of `ValRaw` is safe.
        unsafe { self.bytes }
    }
}

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

Do we ever want to check if either recording or replaying is enabled and then take some action in both cases, rather than checking for just recording and then doing some recording-specific action or just checking replaying and then doing some replaying-specific action? I might be missing something, but I am not seeing any uses of this method.

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

Alternatively, if we don't pursue what @cfallin is sketching out, then I think we can just use std::io::Write directly rather than defining a new RecordWriter trait.

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

Yeah, actually we definitely want to enable record-replay in no-std long term, so I take back my previously suggested option of using std::io::Write instead of RecordWriter and agree that we should do something a little more generic, along the lines of what Chris suggested of having a trait method for appending each kind of event to the trace.

Wasmtime GitHub notifications bot (Jul 25 2025 at 20:11):

fitzgen created PR review comment:

+1 to what @cfallin said about replay being a command, not an option.

Wasmtime GitHub notifications bot (Jul 25 2025 at 22:03):

cfallin commented on PR #11284:

How about scheduling a call when y'all are ready with the 3 of us? That'd probably be best to draw attention to any various areas and for me to ask some questoins in a high-bandwidth way before going off to review on my own.

That'd be great! FWIW, I'm on PTO next week and the week after; please feel free to talk with Arjun directly before then if you both want, or I can join after Aug 11...

Wasmtime GitHub notifications bot (Jul 26 2025 at 00:11):

arjunr2 commented on PR #11284:

@alexcrichton @fitzgen I'll take a pass through the comments early next week, and perhaps we can find a time later next week that works

Wasmtime GitHub notifications bot (Jul 26 2025 at 03:13):

alexcrichton commented on PR #11284:

Sounds good! Feel free to ping me on Zulip when ready

Wasmtime GitHub notifications bot (Jul 28 2025 at 20:04):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 28 2025 at 20:09):

arjunr2 submitted PR review.

Wasmtime GitHub notifications bot (Jul 28 2025 at 20:09):

arjunr2 created PR review comment:

The reason I opted for macros was to prevent unnecessary duplication across call_host and call_host_dynamic, which seemed harder to parse at initial glance, at least earlier. I can do a refactor removing them now and take a look

Wasmtime GitHub notifications bot (Jul 28 2025 at 20:57):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 29 2025 at 01:42):

arjunr2 created PR review comment:

Replay in practice operates very similar to the run command and shares a lot of the top level command line options with it as well.

The replay command as a result would be just a minor super-set of the run setup. It sort of makes sense to do one of two things:

Have a top-level replay command, that just adds additional replay options, and calls run under the hood with it

Add replay options perhaps just for the run command (as opposed to general options)

Leaning towards the former since maybe in the future replay could support different modes of operation

Wasmtime GitHub notifications bot (Jul 29 2025 at 01:43):

arjunr2 submitted PR review.

Wasmtime GitHub notifications bot (Jul 29 2025 at 02:59):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 29 2025 at 03:25):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 29 2025 at 17:01):

fitzgen created PR review comment:

Replay in practice operates very similar to the run command and shares a lot of the top level command line options with it as well.

Shouldn't all the top-level options pretty much be fixed and effectively identical to whatever they were when the trace was recorded? When does it make sense to specify different options than were used when recording? If the answer is "it doesn't make sense" then I don't think we want to force users to manually provide the same options from before in the replay command.

Wasmtime GitHub notifications bot (Jul 29 2025 at 17:01):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Jul 29 2025 at 17:24):

arjunr2 submitted PR review.

Wasmtime GitHub notifications bot (Jul 29 2025 at 17:24):

arjunr2 created PR review comment:

I guess that's true for most options. I think the ones that might be usable are perhaps just profiling

Wasmtime GitHub notifications bot (Jul 29 2025 at 18:17):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Jul 29 2025 at 18:17):

fitzgen created PR review comment:

Ah yeah great point, very cool to profile an execution after the fact and ignore I/O and the external world.

I think we can probably add CLI options one at a time as they make sense to the replay command, and have the default[^0] be "whatever was configured during the recording".

[^0] I think this is implicit/automatic in that the trace will reflect whatever configuration settings were in effect during recording? At least that is true for anything that affects execution.

Wasmtime GitHub notifications bot (Jul 29 2025 at 18:17):

fitzgen edited PR review comment.

Wasmtime GitHub notifications bot (Jul 30 2025 at 00:13):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 30 2025 at 00:42):

arjunr2 submitted PR review.

Wasmtime GitHub notifications bot (Jul 30 2025 at 00:42):

arjunr2 created PR review comment:

You're right, this is now obsolete and removed.

Wasmtime GitHub notifications bot (Jul 31 2025 at 01:50):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Jul 31 2025 at 01:57):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 01 2025 at 02:09):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 05 2025 at 18:34):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 05 2025 at 22:03):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 05 2025 at 22:31):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 05 2025 at 23:58):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 06 2025 at 00:39):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 06 2025 at 16:49):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 06 2025 at 21:17):

arjunr2 updated PR #11284.

Wasmtime GitHub notifications bot (Aug 06 2025 at 21:18):

arjunr2 updated PR #11284.

Last updated: Dec 06 2025 at 06:05 UTC