Re: [PATCH 0/6][RFC] Oprofile JIT code support

[Maynard J. <may...@us...>]

Jens Wilke wrote:

>Hi,
> 
>This is (another) try to address the profiling of jitted code generated by (J)VMs. 
>I tried to incorporate all the previous ideas posted on this list, especially the 
>work from Jason Yeh. The new implementation tries to be modular and extensible 
>and should be easy to integrate. The concept of libopagent is kept, but the ELF 
>files are generated for a complete vma region at the end of the profile run.
>
>The patches are against Oprofile-0.9.2, however the existing code is only touched
>very lightly, so it should be easy to apply it to CVS HEAD or other versions.
>
>  
>
Jens,
Nice piece of work so far.  I applied the relevant patches to a 0.9.2 
oprofile src tree and compiled with no problems.  Your jvmti example 
agent also compiled fine. I had a little trouble running it at first.  I 
tried to start my Java app (with -agentlib:libjvmti_oprofile) before 
starting oprofile, and it failed because it couldn't write the jitdump 
file to /var/lib/oprofile/jitdump.  Your introductory posting implied 
that the directory permissions issue was resolved, but looking at the 
code, I see you create the jitdump directory with world writable 
permissions during 'opcontrol --reset' or 'opcontrol --start'.  So, once 
I ran 'opcontrol --reset' _first_, I was then able to start my Java app 
with the agentlib attached and successfully collect a profile.  Cool.

A recent contribution to OProfile added the concept of "session-dir" to 
specify an arbitrary location for the samples directory.  So when 
forward porting these patches to current OProfile CVS, the hard-coded 
dependency on /var/lib/oprofile will need to be replaced with a 
variable.  For the agentlib, there appears to be a means for passing 
options, but we should also consider honoring an OP_SESSION_DIR 
environment variable, not only for this purpose, but in general.

One issue that may be problematic is your installation of the shared 
library, libopagent.so, and the corresponding header file, 
libopagent.h.  There have been discussions in the past on the 
oprofile-list about providing users with an API, but it is an extra 
maintenance burden that should be avoided if possible.  I outline a 
possible solution below.

John Levon has indicated a willingness in the past to host agent code in 
the OProfile project (_John_, please correct me if I'm misquoting you or 
if you've changed your mind).  This means, for example, the 
jvmti_oprofile agent could be included in the OProfile build, thus 
eliminating the need to export the libopagent API externally.  As with 
other parts of OProfile, the libopagent code could be compiled into a 
static library, and then libjvmti_oprofile.so could be compiled against 
that static library.

Of course, the end user still needs access to the libjvmti_oprofile 
shared library, so that library does need to be installed.  However, the 
only API this library implements is the one declared in 
<java-1-5-0>/include/jvmti.h.  Given that, would we need to version this 
library?

Regards,
-Maynard
[snip]