Re: mapping instructions to dynamic languages like java, python, ruby

[Peter Zijlstra]

On Tue, Apr 22, 2014 at 02:03:05PM -0400, Don Zickus wrote:
> 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.

So we have one JIT supported, I forgot the exact details, but it writes
it symbol table to /tmp/perf-* files. I think the JIT in question will
never over-write symbols in debug mode.

One way to do this would be having two JIT areas, and copy the active
symbols into the 'new' one, and recycle the 'old' one.

Pekka used it for his JIT, so he might have some 'sample' code.

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

Right, we're in the same position.

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

I know Stephane worked with some JIT languages, I'll let him tell.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/