Add measureme integration for profiling the interpreted program

[Aaron1011]

This PR uses the measureme crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The measureme tooling can be used to produce a
call stack from the generated profile data.

Limitations:

• We currently record every single entry/exit. This might generate very
  large profile outputs for programs with a large number of function
  calls. In follow-up work, we might want to explore sampling (e.g. only
  recording every N function calls).
• This does not integrate very well with Miri's concurrency support.
  Each event we record starts when we push a frame, and ends when we pop
  a frame. As a result, the timing recorded for a particular frame will include all of the work Miri does before that frame completes, including executing another thread.

The measureme integration is off by default, and must be enabled via
-Zmiri-measureme=<output_name>

[Aaron1011]

Sample output:

fn main() {
    for i in 0..1000 {
        let a = i.to_string();
    }
    println!("Hello, world!");
}

produces the following Chromium performance profile (generated using the crox tool from https://github.com/rust-lang/measureme):

[oli-obk]

* This does not integrate very well with Miri's concurrency support.
  Each event we record starts when we push a frame, and ends when we pop
  a frame. As a result, switching between virtual threads will cause
  events from different threads to be interleaved. Additionally, the
  recorded for a particular frame will include all of the work Miri does
  before that frame completes, including executing another thread.

how is this done in real executions with threads? Can we reuse the same infrastructure?

[Aaron1011]

how is this done in real executions with threads? Can we reuse the same infrastructure?

You can pass a thread_id parameter to measureme. I don't really know what it does, or what timings actually look like on a multi-threaded compiler. However, I suspect that the fact that the OS schedules the threads makes it easier to get accurate counts, since things like instruction counts will automatically do the right thing. Miri is responsible for 'scheduling' all of its virtual threads, so we'll probably need to give measureme the ability to 'pause' and 'unpause' an interval event.

[RalfJung]

Miri has "thread IDs", why can't we pass those to measureme?

[Aaron1011]

The PR now passes the active thread ID to measureme, which appears to do the right thing:

I suspect that it will take more work to get accurate timing counts when the execution is interleaved, but the stacks should now be shown separately.

[RalfJung]

The PR now passes the active thread ID to measureme, which appears to do the right thing:

That's amazing. :)
Could you update the PR description? I assume at least one of the limitations is resolved by this.

[bors]

☔ The latest upstream changes (presumably #1801) made this pull request unmergeable. Please resolve the merge conflicts.

[Aaron1011]

@RalfJung I've addressed your comments

[RalfJung]

This is a great step forward for performance debugging in Miri, thanks a lot @Aaron1011. :)
@bors r+

[bors]

📌 Commit c89a5d6 has been approved by RalfJung

[bors]

⌛ Testing commit c89a5d6 with merge 178ae8e...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 178ae8e to master...