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
8254723: add diagnostic command to write Linux perf map file #760
Conversation
When using the Linux "perf" tool to do system profiling, symbol names of running Java methods cannot be decoded, resulting in unhelpful output such as: 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 Perf can read a simple text file format describing the mapping between address ranges and symbol names for a particular process [1]. It's possible to generate this already for Java processes using a JVMTI plugin such as perf-map-agent [2]. However this requires compiling third-party code and then loading the agent into your Java process. It would be more convenient if Hotspot could write this file directly using a diagnostic command. The information required is almost identical to that of the existing Compiler.codelist command. This patch adds a Compiler.perfmap diagnostic command on Linux only. To use, first run "jcmd <pid> Compiler.perfmap" and then "perf top" or "perf record" and the report should show decoded Java symbol names for that process. As this just writes a snapshot of the code cache when the command is run, it will become stale if methods are compiled later or unloaded. However this shouldn't be a big problem in practice if the map file is generated after the application has warmed up. [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt [2] https://github.com/jvm-profiling-tools/perf-map-agent
|
/label add serviceability |
@nick-arm |
Webrevs
|
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.
That's a nifty idea! (Kicks himself for not coming up with it himself.)
I do wonder the UX would be even better if we dump the map file at VM shutdown (guarded by flag, sigh). Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running?
test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java
Outdated
Show resolved
Hide resolved
test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java
Outdated
Show resolved
Hide resolved
test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java
Outdated
Show resolved
Hide resolved
/label add compiler |
@plummercj |
Yes that sounds like a good idea. Add a (diagnostic?) option |
const char* method_name = | ||
cb->is_compiled() ? cb->as_compiled_method()->method()->external_name() | ||
: cb->name(); | ||
fs.print_cr(INTPTR_FORMAT " " INTPTR_FORMAT " %s", |
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.
Indentation isn't right.
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.
Do you mean how the arguments are lined up on the continuation line below?
I think we should use this option carefully because nmethod might be unloaded. So we should use this with BTW we can use |
\label remove compiler |
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.
Hi Nick,
this is a very useful idea! I missed this in the past.
Some remarks. I'll try to keep bikeshedding to a minimum since you already have enough input. Mostly ergonomics.
-
Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit.
-
Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc).
-
Not necessary but nice would be a an option to specify location of the dump file.
-
I think it would be nice to have these switches always available, so real product switches. Which would require you to write up a small CSR but I still think it would make sense.
Cheers, Thomas
/label add hotspot-compiler |
@plummercj |
/label remove compiler |
@nick-arm |
OK, makes sense.
The |
@nick-arm this pull request can not be integrated into git checkout 8254723
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
/csr unneeded |
OK sure, I've made it a diagnostic flag. |
@dholmes-ora would you mind helping to remove the csr label? I don't have permission to do it. |
/csr unneeded |
@dholmes-ora determined that a CSR request is not needed for this pull request. |
@nick-arm This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 110 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
@YaSuenag could you re-review the latest changes? |
Sure, the change looks good to me. However I don't understand why CSR is not needed. It introduces new dcmd for Linux. |
I think because interfaces that are for diagnostic purposes don't require a CSR. See question 4 on the CSR FAQs: |
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.
Ok, I reviewed this change. I guess you should close JDK-8254723.
/integrate |
@nick-arm Since your change was applied there have been 136 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 50357d1. |
@nick-arm The command |
5 similar comments
@nick-arm The command |
@nick-arm The command |
@nick-arm The command |
@nick-arm The command |
@nick-arm The command |
@nick-arm The command |
1 similar comment
@nick-arm The command |
When using the Linux "perf" tool to do system profiling, symbol names of
running Java methods cannot be decoded, resulting in unhelpful output
such as:
10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223
Perf can read a simple text file format describing the mapping between
address ranges and symbol names for a particular process [1].
It's possible to generate this already for Java processes using a JVMTI
plugin such as perf-map-agent [2]. However this requires compiling
third-party code and then loading the agent into your Java process. It
would be more convenient if Hotspot could write this file directly using
a diagnostic command. The information required is almost identical to
that of the existing Compiler.codelist command.
This patch adds a Compiler.perfmap diagnostic command on Linux only. To
use, first run "jcmd Compiler.perfmap" and then "perf top" or
"perf record" and the report should show decoded Java symbol names for
that process.
As this just writes a snapshot of the code cache when the command is
run, it will become stale if methods are compiled later or unloaded.
However this shouldn't be a big problem in practice if the map file is
generated after the application has warmed up.
[1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt
[2] https://github.com/jvm-profiling-tools/perf-map-agent
Progress
Testing
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760
$ git checkout pull/760