Messages in this thread | | | From | Brendan Gregg <> | Date | Fri, 9 Oct 2015 13:51:16 -0700 | Subject | Re: [PATCH v7 0/4] perf: add support for profiling jitted code |
| |
On Sun, Oct 4, 2015 at 1:05 PM, Stephane Eranian <eranian@google.com> wrote: > > Brendan, > > On Thu, Oct 1, 2015 at 3:45 PM, Brendan Gregg <brendan.d.gregg@gmail.com> wrote: > > G'Day, > > > > On Wed, Sep 30, 2015 at 11:45 PM, Stephane Eranian <eranian@google.com> wrote: > >> > >> This patch series extends perf record/report/annotate to enable > >> profiling of jitted (just-in-time compiled) code. The current > >> perf tool provides very limited support for profiling jitted > >> code for some runtime environments. But the support is experimental > >> and cannot be used in complex environments. It relies on files > >> in /tmp, for instance. It does not support annotate mode or > >> rejitted code. > >> > >> This patch series adds a better way of profiling jitted code > >> with the following advantages: > >> - support any jitted code environment (some with modifications) > >> - support Java runtime with JVMTI interface with no modifications > >> - provides a portable JVMTI agent library > >> - known to support V8 runtime > >> - known to support DART runtime > >> - supports code rejitting and code movements > >> - no files in /tmp > >> - meta-data file is unique to each run > >> - no changes to perf report/annotate > >> - support per-thread and system-wide profiling > >> - support monitoring of multiple simultaneous Jit runtimes > >> - source level view in perf annotate > >> > >> The support is based on cooperation with the runtime. For Java runtimes, > >> supporting the JVMTI interface, there is no change necessary. For other > >> runtimes, modifications are necessary to emit the meta-data to support > >> symbolization, annotation, source lines correlation of the samples. > >> Those modifications are relatively straighforward, some have been > >> implemented in V8 and DART. > >> > >> The jit environment emits a binary dump file which contains the jitted > >> code (in raw format) and meta-data describing the mapping of functions. > >> The binary format is documented in the jitdump.h header file. It is > >> adapted from the OProfile jitdump format. > > > > While this is impressive work, I don't think I'd use it very much, and > > I wouldn't encourage others too either. Is it right that this approach > > needs to be turned on from runtime start, and will constantly emit > > timestamped JIT records? I'd use that as a backup for existing > > techniques for perf_events and jitted runtimes. > > > This boils down that when does the JIT runtime emit the jitdump data? > In the case of openJDK and given how I wrote the agent, it needs to > run from start to finish. In order for perf to have full visibility, it needs > to get info about all the code that has been jitted so far. This could be > done after start if there was somehow a protocol to handle this in the > runtime, like a signal. It would just need to dump the current status, including > all the code. The rest of the support would work. In other words, if there was > a way to signal to the runtime that it is being monitored and that it needs to > dump its state, then everything would work. To avoid generating more dumps, > the runtime would also have to be informed that monitoring has stopped.
Ok, so it's possible that an on-demand approach could work, if the agent can be modified. And since perf-map-agent made this transition (https://github.com/jrudolph/perf-map-agent), examples of how to do this are probably in its git history. :) The outcome could well be something like:
perf record -F 99 -a -g -- perf_java_agent --sleep 10
Where a perf_java_agent tool attached to all Javas, dumped initial symbols, and then logged timestamped symbols during the run (--sleep 10), then detached at the end. That would be ideal. Which just means changing the Java agent, not the perf implementation.
Brendan
| |