Closed brendangregg closed 9 years ago
Thanks, @brendangregg. These are useful additions.
Regarding the live updates I was also thinking about playing around with attaching to the Java process instead (see #3). I haven't tried it yet but it seems the JVMTI API will then only report (or replay) current compilation addresses.
I'm (obviously!) very interested in the frame-pointer hack, what's your approach for this?
:+1:
@brendangregg I'm releasing this library under GPLv2. So, do you want to contribute this change under GPLv2?
@brendangregg I restructured things a bit and now the agent works differently. There's now a small Java class that attaches to a running pid and attaches the agent. On attaching the agent uses JVMTI's GenerateEvents
function to generate a current view of the map file. You can reattach as often as you like and everytime the map file will be truncated and rewritten with fresh data. Options are applied per run as well so you can choose different output formats without having to restart the target process.
Does this address the issue you tried to solve with the livemap
option?
I didn't yet build in something like your msig
option, do you want to update this PR based on the new code? Otherwise, I can do that as well.
However, there's now a new unfold
option which generates a lot more entries based on the map of methods inlined into a single method. In many cases, the added information doesn't really help and obscures the overview you can get by just looking at the root methods that get inlined. In some cases, however, you may wonder why a particular method is reported and by enabling the option you can find out if time is spent just in a method that was inlined into the method that was previously reported.
Yes, GPLv2 is fine. I'll try the new approach for getting clean map files, thanks! If that works it will be great - we don't need to have the agent preloaded.
Since the code has changed a bit, I think I can just close this PR and generate a new one later.
The new perf-map-agent does create the map file when using the command line from perf-java, however, I only see it work once. If I run it again, the map file is not created.
Ah, it's just an issue with closing the map file. Pull request in a moment...
I published and described my frame pointer hack, asking if Oracle were interested in including something like it in OracleJDK: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016477.html
Wow, this is very cool.
Btw. as shown with the new unfold
option we can recover all the inlined frames as well. It's just not supported by the perf-<pid>.map
file to have several "virtual frames" per PC for the inlined methods.
If it was just for the flamegraphs we could split the whole process in two (with your JDK patch applied):
perf record
and use the agent for collecting perf.map-like data including the inlined frames in a custom formatperf script
or whatever to spit out the raw stack traces and do the symbol frame mapping manually and in the process inflate the "virtual frames" using the info from the custom fileAnother route would be changing the perf-<pid>.map
format to account for virtual stack frames.
Just a few small improvements, if you want them:
I also have a fix (or rather, a hack) in-hand for the frame pointer issue I need to publish as well...