Oprofile JIT Code Proposal

[Jason Y. <jas...@am...>]

hi,

I decided to start a new thread instead of adding to the previous thread 
cluttered with somewhat unrelated information.  A simple jvmti example 
is attached with the mail. 

In the example, JVMTI_EVENT_COMPILED_METHOD_LOAD and 
JVMTI_EVENT_DYNAMIC_CODE_GENERATED are hooked to callbacks which will 
use libopagent API to write the JIT code into a ELF file in 
/var/lib/oprofile/jit/<pid>/.  The callbacks would also use the API to 
store JIT info in shared memory to be read by the daemon.

The daemon also uses libopagent API to read the shared memory retrieving 
JIT info.  The JIT info is then used to process each sample from the 
event buffer.  The JIT processing takes place before the anonymous 
sample processing.  In the current patch, all ELF files are stored in 
/var/lib/oprofile/jit/<pid>, and this path will be the path reported by 
opreport.  Since there is no difference between the ELF representation 
of the JIT code and any other executables in the system, opreport and 
opannotate do not need any patch.

There are still some items on my TODO list, namely:
1. I have not verify whether oparchive works with the current patch.
2. opcontrol --reset currently would wipe out everything in 
/var/lib/oprofile/jit/ directory.  This might not be the action user 
expects.
3. More testing.  I have been using primarily jbb to test the patch.  I 
have no idea how well or badly the patch work under different kind of 
workload.  If anyone has any suggestion on the tests to run, please let 
me know.
4. Shared memory and semaphore are sometimes undeleted. 


Jason