Will Cohen <wcohen@redhat.com>
Sent by: oprofile-list-admin@lists.sourceforge.net

01/09/2004 02:32 PM

       
        To:        oprofile-list <oprofile-list@lists.sourceforge.net>
        cc:        
        Subject:        OProfile Support for Java JIT code



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

(FIXME: case where PID reused?)

We write using the tgid(owning PID) and keep the files open while the
JVM is running.  We close the files after the java process terminates.
If a second java process was started with the same tgid we overwrite the
log file.

(FIXME: what about names issues profiling where PID discarded?)

Please clarify this question.

(FIXME: what about getting rid of stale files?)

 We use an executable that removes closed jit logs in the specified directory.

(FIXME: debugging information? JIT machine code -> class? class-> Java source?)
We currently don't support line of code JVMPI events, they are not supportted on
most java implementations. We can dump the jitted machine code for dissassembly.


The profiling agent would use the JVMPI_EVENT_COMPILED_METHOD_LOAD
event provided by the JVM.


(FIXME: more detail on what is written out.)
The event spec is shown below, although line number isn't usally implemented.


JVMPI_EVENT_COMPILED_METHOD_LOAD
Sent when a method is compiled and loaded into memory.
struct {
   jmethodID method_id;        
   void *code_addr;            
   jint code_size;            
   jint lineno_table_size;    
   
JVMPI_Lineno *lineno_table;
} compiled_method_load;

Contents:
method_id - method being compiled and loaded.
code_addr - address where compiled method code is loaded.
code_size - size of compiled code.
lineno_table_size - size of line number table.
lineno_table - table mapping offset from beginning of method to the src file line number.



jprof writes 1) cycle timestamp
                 2) starting address
                 3) size
                 4) code flag
                 5) fully qualified method name
                 6) optional machine code.





(FIXME: how to deal with high-to-low allocation of JITed code segments
efficiently? Just leave the sample address as VMA and have a post
processing pass that read in the JITed files and samples and sorts the
JITed methods, combines them into a single block, converts the VMAs
into offset, new files written, so this doesn't screw up the daemon or
currently running java code.)


Agreed!