-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Adds perf jitdump support #360
Conversation
3bb0a62
to
94001b3
Compare
Shouls this be put in a new crate independent of wasmtime? |
@bjorn3 @yurydelendik @sunfishcode |
9314319
to
676235a
Compare
@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. |
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. |
e738faa
to
8df39da
Compare
@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. |
8df39da
to
74e4be0
Compare
@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 |
74e4be0
to
228fbb3
Compare
There was a problem hiding this 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 :-).
228fbb3
to
16dac20
Compare
16dac20
to
c1ea03e
Compare
Rebased to fix conflicts with the latest changes. |
c1ea03e
to
832220c
Compare
97e3549
to
8565188
Compare
6e508c8
to
32bae77
Compare
@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. |
43a04d4
to
4441788
Compare
There was a problem hiding this 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
4441788
to
478a2a5
Compare
There was a problem hiding this 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)
478a2a5
to
81e58ec
Compare
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
97c00c2
to
b070011
Compare
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. |
There was a problem hiding this 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!( |
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 == "?" { |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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.