Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds perf jitdump support #360

Merged
merged 1 commit into from
Feb 21, 2020

Conversation

jlb6740
Copy link
Contributor

@jlb6740 jlb6740 commented Sep 23, 2019

Patch adds support for the perf jitdump file specification.
With this patch it should be possible to see profile data for code
generated and maped at runtime. Specifically the patch adds support
for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in
the specification. Dumping jitfiles is enabled with the --jitdump
flag. When the -g flag is also used there is an attempt to dump file
and line number information where this option would be most useful
when the WASM file already includes DWARF debug information.

wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 3bb0a62 to 94001b3 Compare September 24, 2019 08:21
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
wasmtime-runtime/src/jit_dump.rs Outdated Show resolved Hide resolved
@bjorn3
Copy link
Contributor

bjorn3 commented Sep 24, 2019

Shouls this be put in a new crate independent of wasmtime?

@jlb6740
Copy link
Contributor Author

jlb6740 commented Sep 24, 2019

Shouls this be put in a new crate independent of wasmtime?

@bjorn3 @yurydelendik @sunfishcode
We can definitely do that .. if that's preferred. In fact, I wanted to provide similar support for Vtune and was hoping to follow a similar implementation structure based on the feedback for this patch .. perhaps some general crate like wasmtime-perf-tools or are you thinking something else? At the same time, I would personally like to get this patch in it's current structure and iterate on suggestions like refactoring if that is reasonable and possible. Also note ... support for other record types are needed in the future as well so more patches are coming. So we can update the crate now, or in the future or not at all, whichever is preferred I am definitely OK with.

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 8 times, most recently from 9314319 to 676235a Compare September 25, 2019 01:30
@jlb6740
Copy link
Contributor Author

jlb6740 commented Sep 25, 2019

@bjorn3 Thanks for all the suggestions, they are all very helpful. Depending on how folks would like to structure this (the comment about where to put jit_dump.rs), this current iteration may be ready. Let me know your thoughts on whether you'd like to move this file and/or see it as a separate crate.

@bjorn3
Copy link
Contributor

bjorn3 commented Sep 25, 2019

Let me know your thoughts on whether you'd like to move this file and/or see it as a separate crate.

I am fine with both. Don't know how others think about it.

@yurydelendik
Copy link
Contributor

Let me know your thoughts on whether you'd like to move this file and/or see it as a separate crate.

I am fine with both. Don't know how others think about it.

I personally don't see an urgency in creating a crate for one file. If it a question about viewing it as an optional "feature", maybe it a good idea to use rust features for that.

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 2 times, most recently from e738faa to 8df39da Compare September 26, 2019 00:22
@jlb6740
Copy link
Contributor Author

jlb6740 commented Sep 26, 2019

@bjorn3 @yurydelendik @sunfishcode FYI .. the last push rebased against recent updates to wasmtime and also removed unneeded dependencies in the cargo.toml. Let me know if there is anything else.

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 8df39da to 74e4be0 Compare September 26, 2019 17:50
@jlb6740
Copy link
Contributor Author

jlb6740 commented Sep 26, 2019

@bjorn3 @yurydelendik @sunfishcode Hi ... I do not make any changes to lightbeam, but formatting checks fail for code under lightbeam causing not all checks to pass. How should this be handled? https://dev.azure.com/CraneStation/Wasmtime/_build/results?buildId=1102

@bjorn3
Copy link
Contributor

bjorn3 commented Sep 26, 2019

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 74e4be0 to 228fbb3 Compare September 26, 2019 20:45
Copy link
Member

@sunfishcode sunfishcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for trimming the depenencies :-).

wasmtime-runtime/Cargo.toml Outdated Show resolved Hide resolved
wasmtime-runtime/src/lib.rs Outdated Show resolved Hide resolved
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 228fbb3 to 16dac20 Compare September 26, 2019 23:44
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 16dac20 to c1ea03e Compare October 28, 2019 23:37
@jlb6740
Copy link
Contributor Author

jlb6740 commented Oct 28, 2019

Rebased to fix conflicts with the latest changes.

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from c1ea03e to 832220c Compare October 28, 2019 23:50
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 2 times, most recently from 97e3549 to 8565188 Compare November 6, 2019 19:53
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 6 times, most recently from 6e508c8 to 32bae77 Compare February 12, 2020 21:23
@jlb6740
Copy link
Contributor Author

jlb6740 commented Feb 12, 2020

@yurydelendik @alexcrichton Thanks for the comments. This latest push should have improvements to the previous. Now we use a generic interface for accessing the profiler API. In addition there has been some other cleanup w.r.t. how the profiler is created and stored for thread safety. Hopefully the code here is cleaner and easier to expand upon. Please let me know if you have more suggestions.

@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 6 times, most recently from 43a04d4 to 4441788 Compare February 12, 2020 22:00
Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really good. I did not look into JitDumpAgent logic in details yet, but I would like to address the Clone workaround involving Arc<Mutex<Box<dyn..>>> (?) to reduce complexity there first. Thanks

Cargo.toml Outdated Show resolved Hide resolved
crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 4441788 to 478a2a5 Compare February 18, 2020 22:54
Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good.

I would like to see better "defined" error handling story before landing:

  • ignore all errors at module_load and just skip the invalid data and unsupported OS
    • print some messages in the console?
  • return errors back to wasmtime-jit
    • propagate it as instantiation error
    • ignore it there (and print messages)

crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
crates/jit/src/instantiate.rs Outdated Show resolved Hide resolved
crates/profiling/src/jitdump.rs Outdated Show resolved Hide resolved
@jlb6740 jlb6740 closed this Feb 20, 2020
@jlb6740 jlb6740 reopened this Feb 20, 2020
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch from 478a2a5 to 81e58ec Compare February 20, 2020 04:15
Patch adds support for the perf jitdump file specification.
With this patch it should be possible to see profile data for code
generated and maped at runtime. Specifically the patch adds support
for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in
the specification. Dumping jitfiles is enabled with the --jitdump
flag. When the -g flag is also used there is an attempt to dump file
and line number information where this option would be most useful
when the WASM file already includes DWARF debug information.

The generation of the jitdump files has been tested on only a few wasm
files. This patch is expected to be useful/serviceable where currently
there is no means for jit profiling, but future patches may benefit
line mapping and add support for additional jitdump record types.

Usage Example:
Record
  sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g
  --jitdump test.wasm
Combine
  sudo perf inject -v -j -i perf.data -o perf.jit.data
Report
  sudo perf report -i perf.jit.data -F+period,srcline
@jlb6740 jlb6740 force-pushed the add-jit-dump-support branch 4 times, most recently from 97c00c2 to b070011 Compare February 20, 2020 19:36
@jlb6740
Copy link
Contributor Author

jlb6740 commented Feb 20, 2020

Looks really good.

I would like to see better "defined" error handling story before landing:

  • ignore all errors at module_load and just skip the invalid data and unsupported OS

    • print some messages in the console?
  • return errors back to wasmtime-jit

    • propagate it as instantiation error
    • ignore it there (and print messages)

I agree. For now took option 1, made some changes to the error handling .. encapsulated the two main kind of errors in a jitdumperror and propagate everything up to methods in jitdump that print some messages. There are two cases where we call unwrap() .. one is when we are access an option for the jitdump file to exist. This is already guarded at the entry interface function "module_load" so I suspect this should be ok. The other time is when parsing the debug_image in the call dump_from_debug_image.

Hopefully these are improvements in simplicity and clarity but it may could use some modifications. Let me know.

Thanks.

Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mentioned couple of issues below that might simplify reading of the code. There are some problem in reading of DWARF data, but I not planing fixing that at this moment. We are going to address that as we iterate in the future PRs.


if let Some(img) = &dbg_image {
if let Err(err) = self.dump_from_debug_image(img, module_name, addr, len, pid, tid) {
println!(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's make it eprintln!() , here and elsewhere in this file


let mut attrs = entry.attrs();
while let Some(attr) = attrs.next()? {
if let Some(n) = attr.name().static_string() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to convert it to string: attr.name() == gimli::constants::DW_AT_low_pc

The match construct might be a better choice here match attr.name() { gimli::constants::DW_AT_low_pc => ....

if let Ok(s) = dwarf.debug_str.get_str(offset) {
clr_name.push_str("::");
clr_name.push_str(&s.to_string_lossy()?);
clr_name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the clr_name = above is not need, then this if-return can be removed.

continue;
}
// TODO: Temp check to make sure well only formed data is processed.
if clr_name == "?" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly false (unless "?" is a module_name)

it might be a better choice to make clr_name and func_name as Option<String> and set them valid e.g. Some(format!("{}::{}", module_name, s.to_string_lossy()?)) when needed.

Copy link
Contributor

@yurydelendik yurydelendik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll land this PR since it is mostly a base for profiling support. There is basic support for jitdump present here, but needs improvements (see comments above). The further work can be done in different PRs.

Thank you for the patch.

@yurydelendik yurydelendik merged commit 9c6150b into bytecodealliance:master Feb 21, 2020
@jlb6740 jlb6740 deleted the add-jit-dump-support branch May 5, 2020 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants