linux-kernel - Re: [PATCH v7 0/4] perf: add support for profiling jitted code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAE40pdeQD1qLMZgK7OU6LZR3SuW_sXUk1HL8tYsoQq3WmtLpNg@mail.gmail.com>
Date:	Fri, 9 Oct 2015 13:51:16 -0700
From:	Brendan Gregg <brendan.d.gregg@...il.com>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...ux.intel.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Rose Belcher <cel@...ibm.com>, David Ahern <dsahern@...il.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	John Mccutchan <johnmccutchan@...gle.com>
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@...gle.com> wrote:
>
> Brendan,
>
> On Thu, Oct 1, 2015 at 3:45 PM, Brendan Gregg <brendan.d.gregg@...il.com> wrote:
> > G'Day,
> >
> > On Wed, Sep 30, 2015 at 11:45 PM, Stephane Eranian <eranian@...gle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/