Re: OProfile Support for Java JIT code

[Will C. <wc...@re...>]

John Levon wrote:
> On Tue, Jan 13, 2004 at 11:09:30AM -0600, Jimmy DeWitt wrote:
> 
> 
>>(FIXME: where would these files located?)
>>Default is where the java command is issued from.  We have an jprof option 
>>to
>>write the log to any directory with writeable permissions. We suggest that
>>the jprof output is logged into a "jprof" directory owned by OProfile. 
> 
> 
> My suggestion would be to place the files as needed into
> /var/lib/oprofile/current/{java}
> 
> That way the Java stuff is placed in the same dir tree as "normal"
> sample files from the rest of the sampling session.

/var/lib/oprofile/current/{java} is okay with me.

> I don't know what the file names themselves would look like. It might
> well be useful to follow the basic naming scheme oprofile uses.

The data files from Java are almost certain to have the PID because the 
JIT code generated could be different from run to run. However, given 
that the JIT code will be in one file, the samples will not be broken 
into application binary and dependent binaries. Is there going to be a 
problem having PID in the file names with files mixed into the sample 
directory with filenames without PID. I haven't looked at the code that 
handles that part of the code that handles sample specification.

>>(FIXME: what about getting rid of stale files?)
>> We use an executable that removes closed jit logs in the specified 
>>directory.
> 
> 
> I'm not sure that's what Will means by stale files. Will ?

I meant files that are no longer valid/useful. With the PID in the name 
there could be potentially a lot of sample files that are no longer 
useful. OProfile can clear out the sample directory (--reset) and it can 
save a session (--save), but OProfile doesn't selectively remove sample 
files. Maybe make the files with PID in the name have the same owner as 
the process, so that user could remove them without being root.

>>We currently don't support line of code JVMPI events, they are not 
>>supportted on most java implementations. 
> 
> 
> Nonetheless, we should consider the ramifications of supporting this in
> the future. In particular the file format.

Even without the line number information OProfile should be able to map 
things to the appropriate method. Ideally, OProfile should be able to 
map the samples back to the original Java code. However, I can see why 
the JIT might skip handling line information.

-Will