public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: peterz@infradead.org, acme@redhat.com, jolsa@redhat.com,
	namhyung@kernel.org
Cc: linux-kernel@vger.kernel.org, eranian@google.com,
	andi@firstfloor.org, wcohen@redhat.com
Subject: mapping instructions to dynamic languages like java, python, ruby
Date: Tue, 22 Apr 2014 14:03:05 -0400	[thread overview]
Message-ID: <20140422180305.GK8488@redhat.com> (raw)

Hi,

I was discussing recently with Will Cohen about how to get perf to
understand dynamic languages (java, python, ruby) better.  Currently, perf
samples and address, stores it in a mmap region (from the kernel side),
the mmap region is read (from user side async) and stored in a file.

During 'perf report' those instruction addresses are looked up in the
dwarf table?? of the binary they were mapped to, to resolve their symbols.

This works great for statically compiled binaries (like C), where the
addresses stay the same during each run of the binary.

However, for dynamic languages like java, python, ruby not only do those
addresses change each run of the binary, those address can change
_during_ the execution of the binary.  As a result the normal perf
collection method fails.

Oprofile has a mechanism to work around this, by creating a debug library
for java that records class information.  This library is linked?? during
the initial execution of the java program and all its symbol info is
recorded in a temp file.  During post-processing this temp file is read
back in and symbol info is obtained.

However, this approach is java specific and only works for programs that
initially start with it (can not attach to running programs).

Thoughts have come up about using a SIGPROF from the kernel to signal the
userspace interpreters to dump information to a temp file that can be used
later during post-processing.

Does anyone have any thoughts or experience on this?

Cheers,
Don


             reply	other threads:[~2014-04-22 18:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22 18:03 Don Zickus [this message]
2014-04-22 18:26 ` mapping instructions to dynamic languages like java, python, ruby Peter Zijlstra
2014-04-22 19:05 ` Stephane Eranian
2014-04-22 19:19   ` David Ahern
2014-04-22 21:23   ` Don Zickus
2014-04-23  6:03   ` Namhyung Kim
2014-04-22 20:54 ` Andi Kleen
2014-04-22 21:24   ` Stephane Eranian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140422180305.GK8488@redhat.com \
    --to=dzickus@redhat.com \
    --cc=acme@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=wcohen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox