search

jvm-profiling-tools / perf-map-agent

A java agent to generate method mappings to use with the linux `perf` tool
GNU General Public License v2.0
1.65k stars 260 forks source link

flush buffers, and options for livemap and msig #8

Closed brendangregg closed 9 years ago

brendangregg commented 9 years ago

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...

jrudolph commented 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?

ceeaspb commented 9 years ago

:+1:

jrudolph commented 9 years ago

@brendangregg I'm releasing this library under GPLv2. So, do you want to contribute this change under GPLv2?

jrudolph commented 9 years ago

@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.

brendangregg commented 9 years ago

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.

brendangregg commented 9 years ago

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.

brendangregg commented 9 years ago

Ah, it's just an issue with closing the map file. Pull request in a moment...

brendangregg commented 9 years ago

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

jrudolph commented 9 years ago

Wow, this is very cool.

jrudolph commented 9 years ago

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):

  1. collect raw data with perf record and use the agent for collecting perf.map-like data including the inlined frames in a custom format
  2. use perf 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 file

Another route would be changing the perf-<pid>.map format to account for virtual stack frames.