Review

Author: alexcrichton

crates/api/src/runtime.rs

@@ -379,13 +379,14 @@ pub enum OptLevel {
     SpeedAndSize,
 }
 
-/// Select which profiling technique to use
+/// Select which profiling technique to support.
 #[derive(Debug, Clone, Copy)]
 pub enum ProfilingStrategy {
-    /// No profiler support
+    /// No profiler support.
     None,
 
-    /// Collect profile for jitdump file format, used with `perf` on Linux
+    /// Collect profiling info for "jitdump" file format, used with `perf` on
+    /// Linux.
     JitDump,
 }
 

crates/profiling/src/jitdump_linux.rs

@@ -221,8 +221,11 @@ impl ProfilingAgent for JitDumpAgent {
 
 impl State {
     /// Returns timestamp from a single source
-    #[allow(unused_variables)]
     fn get_time_stamp(&self) -> u64 {
+        // We need to use `CLOCK_MONOTONIC` on Linux which is what `Instant`
+        // conveniently also uses, but `Instant` doesn't allow us to get access
+        // to nanoseconds as an internal detail, so we calculate the nanoseconds
+        // ourselves here.
         unsafe {
             let mut ts = mem::MaybeUninit::zeroed();
             assert_eq!(
@@ -231,12 +234,11 @@ impl State {
             );
             let ts = ts.assume_init();
             // TODO: What does it mean for either sec or nsec to be negative?
-            (ts.tv_sec * 1000000000 + ts.tv_nsec) as u64
+            (ts.tv_sec * 1_000_000_000 + ts.tv_nsec) as u64
         }
     }
 
     /// Returns the ELF machine architecture.
-    #[allow(dead_code)]
     fn get_e_machine(&self) -> u32 {
         match target_lexicon::HOST.architecture {
             Architecture::X86_64 => elf::header::EM_X86_64 as u32,
@@ -247,7 +249,6 @@ impl State {
         }
     }
 
-    #[allow(dead_code)]
     fn write_file_header(&mut self) -> Result<()> {
         let header = FileHeader {
             timestamp: self.get_time_stamp(),

docs/assets/perf-annotate-fib.png

@@ -98,4 +98,55 @@ You shouldn't need to do anything else to get this information into `perf`. The
 perf collection data should automatically pick up all this dwarf debug
 information.
 
+### `perf` example
+
+Let's run through a quick example with `perf` to get the feel for things. First
+let's take a look at some wasm:
+
+```rust
+fn main() {
+    let n = 42;
+    println!("fib({}) = {}", n, fib(n));
+}
+
+fn fib(n: u32) -> u32 {
+    if n <= 2 {
+        1
+    } else {
+        fib(n - 1) + fib(n - 2)
+    }
+}
+```
+
+To collect perf information for this wasm module we'll execute:
+
+```sh
+$ rustc --target wasm32-wasi fib.rs -O
+$ perf record -k mono wasmtime --jitdump fib.wasm
+fib(42) = 267914296
+[ perf record: Woken up 1 times to write data ]
+[ perf record: Captured and wrote 0.147 MB perf.data (3435 samples) ]
+$ perf inject --jit --input perf.data --output perf.jit.data
+```
+
+And we should have all out information now! We can execute `perf report` for
+example to see that 99% of our runtime (as expected) is spent in our `fib`
+function. Note that the symbol has been demangled to `fib::fib` which is what
+the Rust symbol is:
+
+```
+$ perf report --input perf.jit-data
+```
+
+![perf report output](assets/perf-report-fib.png)
+
+Alternatively we could also use `perf annotate` to take a look at the
+disassembly of the `fib` function, seeing what the JIT generated:
+
+```
+$ perf annotate --input perf.jit-data
+```
+
+![perf annotate output](assets/perf-annotate-fib.png)
+
 [`Config::debug_info`]: https://bytecodealliance.github.io/wasmtime/api/wasmtime/struct.Config.html#method.debug_info