History log of /wasmtime-44.0.1/pulley/src/interp/debug.rs (Results 1 – 2 of 2)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0
# 1d1c06f3 16-Jan-2025 Alex Crichton <[email protected]>

Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously

Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously through the use of native
profilers, but the downside of that approach is that you can find hot
instructions but it's not clear in what context the hot instructions are
being executed nor what functions are hot. The goal of this profiler is
to show pulley bytecode and time spent in bytecode itself to better
understand the shape of code around a hot instruction to identify new
macro opcodes for example.

The general structure of this new profiler is:

* There is a compile-time feature for Pulley which is off-by-default
where, when enabled, Pulley will record its current program counter
into an `AtomicUsize` before each instruction.

* When the CLI has `--profile pulley` Wasmtime will spawn a sampling
thread in the same process which will periodically read from this
`AtomicUsize` to record where the program is currently executing.

* The Pulley profiler additionally records all bytecode through the use
of the `ProfilingAgent` trait to ensure that the recording has access
to all bytecode as well.

* Samples are taken throughout the process and emitted to a
`pulley-$pid.data` file. This file is then interpreted and printed by
an "example" program `profiler-html.rs` in the `pulley/examples`
directory.

The end result is that hot functions of Pulley bytecode can be seen and
instructions are annotated with how frequently they were executed. This
enables finding hot loops and understanding more about the whole loop,
bytecodes that were selected, and such.

* Add missing source file

* Check the profile-pulley feature in CI

* Miscellaneous fixes for CI

* Fix type-checking of `become` on nightly Rust

* Fix more misc CI issues

* Fix dispatch in tail loop

* Update test expectations

* Review comments

* Fix a feature combo

show more ...


Revision tags: v28.0.1, v28.0.0
# c2fa8171 11-Dec-2024 Alex Crichton <[email protected]>

pulley: Add simple debugging support (#9796)

This commit adds a `debug.rs` to Pulley to print out the instruction
being executed and the state of all registers between instructions. This
is turned o

pulley: Add simple debugging support (#9796)

This commit adds a `debug.rs` to Pulley to print out the instruction
being executed and the state of all registers between instructions. This
is turned off by default and does not have a runtime or
environment-based configuration value. Instead changing this requires
changing source code for now. This enables the interpreter loop to
unconditionally use this "debugger" where it'll compile away to nothing
in release/benchmarking situations.

This commit additionally adds this support to the `tail_loop` module and
fixes a few issues there such as it accidentally not being tested in CI
as well as a new `#[cfg]` to use it on stable rust with normal `return`
under the assumption that LLVM is highly likely to do TCO.

show more ...