Stream: git-wasmtime

Topic: wasmtime / PR #1310 Enable jitdump profiling support by d...

Wasmtime GitHub notifications bot (Mar 13 2020 at 17:32):

alexcrichton opened PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 13 2020 at 17:57):

bjorn3 submitted PR Review.

Wasmtime GitHub notifications bot (Mar 13 2020 at 17:58):

bjorn3 created PR Review Comment:

performance, so typically when executing wasm you'll be quite interested in how

Wasmtime GitHub notifications bot (Mar 13 2020 at 18:37):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 13 2020 at 18:39):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 13 2020 at 18:40):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 13 2020 at 19:21):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:04):

jlb6740 submitted PR Review.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:04):

jlb6740 created PR Review Comment:

This is great. I see the link to it in SUMMAR.mdY, but does the SUMMARY.md get published anywhere? I could only find it on the github view of this branch by clicking through the source tree and not any official links to docs found on the opening Readme.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:06):

jlb6740 edited PR Review Comment.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:34):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:34):

alexcrichton created PR Review Comment:

Ah yeah these are auto-published from the master branch at https://bytecodealliance.github.io/wasmtime/

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:35):

fitzgen submitted PR Review.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:35):

fitzgen created PR Review Comment:

In particular the SUMMARY.md is the table of contents on the left hand side. More info in the mdbook user guide: https://rust-lang.github.io/mdBook/format/summary.html

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:44):

jlb6740 submitted PR Review.

Wasmtime GitHub notifications bot (Mar 13 2020 at 22:44):

jlb6740 created PR Review Comment:

@fitzgen .. Ahh I see. Thanks. I clicked on docs here linked to at the bottom here: https://github.com/alexcrichton/wasmtime/tree/profiling for this pr, but I didn't notice that link was going to be linking back to master. Got to be carefully following links like that.

Wasmtime GitHub notifications bot (Mar 17 2020 at 16:39):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 19 2020 at 21:23):

alexcrichton requested fitzgen for a review on PR #1310.

Wasmtime GitHub notifications bot (Mar 19 2020 at 21:24):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen submitted PR Review.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen submitted PR Review.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen created PR Review Comment:

    /// No profiler support.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen created PR Review Comment:

/// Select which profiling technique to support.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen created PR Review Comment:

    /// Collect profiling info for the "jitdump" file format, used with `perf` on Linux.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen created PR Review Comment:

Why aren't we using std::time::Instant::now here? If there's a reason, it deserves a comment. If there isn't a reason, then we should use it ;)

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:05):

fitzgen created PR Review Comment:

A screenshot here would be nice :+1:

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:33):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:33):

alexcrichton created PR Review Comment:

Good idea! Looks like though Instant doesn't allow accessing nanoseconds-since-the-epoch, so I'll leave a comment saying that.

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:44):

alexcrichton updated PR #1310 from profiling to master:

This the result of some of the investigation I was doing for #1017. I've
done a number of refactorings here which culminated in a number of
changes that all amount to what I think should result in jitdump support being
enabled by default:

• Pass in a list of finished functions instead of just a range to
  ensure that we're emitting jit dump data for a specific module rather
  than a whole CodeMemory which may have other modules.

• Define ProfilingStrategy in the wasmtime crate to have everything
  locally-defined

• Add support to the C API to enable profiling

• Documentation added for profiling with jitdump to the book

• Split out supported/unsupported files in jitdump.rs to avoid having
  lots of #[cfg].

• Make dependencies optional that are only used for jitdump.

• Move initialization up-front to JitDumpAgent::new() instead of
  deferring it to the first module.

• Pass around Arc<dyn ProfilingAgent> instead of
  Option<Arc<Mutex<Box<dyn ProfilingAgent>>>>

The jitdump Cargo feature is now enabled by default which means that
our published binaries, C API artifacts, and crates will support
profiling at runtime by default. The support I don't think is fully
fleshed out and working but I think it's probably in a good enough spot
we can get users playing around with it!

Wasmtime GitHub notifications bot (Mar 20 2020 at 16:44):

alexcrichton merged PR #1310.

Last updated: Dec 23 2024 at 12:05 UTC