Hmm, in fact we implemented somewhat simple architecture, based on JVM TI.
VM itself maintains private executable file mapping for all regions
where executable code is stored.
Files got deleted immediately after mapping, so no /tmp pollution.
VM starts with an agent, which listens for dynamic code generation
events and writes
symbolic information in format "file":"symbol":"offset":"size" on disk.
"file" is selected basing on maps from /proc/self/maps - proper file for
Later reporter with patch I sent just dumps top methods.
Also I haven't read your discussion, idea of fake ELF also come up, but
was rejected due:
- Java classes/methods can be named in Unicode and contain symbols not
expected to be presented in
ELF symbol table
- hard to maintain, as have to be supported for all arches somewhat
- seems to be too kludgy
I f you're interested, I can send JVM TI agent doing most of VM part
(works on current Hotspot).
John Levon wrote:
> <>On Tue, May 24, 2005 at 06:19:23PM +0400, Nikolay Igotti wrote:
> Hi Nikolay, have you been following the discussions we've been having
> about how best to integrate OProfile and the JVM? We'd agreed that, for
> a number of reasons, the best approach is to generate fake ELF files for
> Java invocations, and use that directly.
> See these threads:
> We'd really like to see an implementation along these lines. What do you
> think? I don't think it'd be too difficult, and it means you avoid
> having to grub around in the post-profiling code. Also you can borrow
> some of the ELF-writing code from the previous IBM patch.