Re: Oprofile JIT enhancement questions

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

hi Jens,

There was a patch for Oprofile 0.9.1 send last year that has the JIT 
enhancement, and there were a few minor bug fixes after the initial 
patch. If you are having problem finding the patch from the mail 
archive, I am happy to send out the slightly updated ones.

Jens Wilke wrote:
> Hi Jason!
>
> I am currently starting work on this item and investigating your design proposal of last year.
>
> A few questions:
>
> - Why did you use shared memory? I think it might be better to write out any generated
>   code sequencially to a file and generate the ELF file after profiling stopped.
>   This way we can collect all methods belonging to one seciton in one ELF file. Besides, there
>   will be no expensive operations going on during profiling.
>   
I chose shared memory so the Oprofile daemon is able to have a picture 
of what's going on regarding the jit functions and to map the samples 
with address in the jit ranges. This decision was made primarily to 
minimize changes to the daemon and follow the paradigm used by the 
daemon to process samples from regular binary files rather than based on 
other criteria such as efficiency and avoid expensive operations.

 From my observation of profiles taken with the current implementation, 
I found the cost to write the ELF file during a profile is not all that 
much and the cost to map the samples to jit function are the greatest 
over the duration of a profile. It could be that the code is not using 
optimal algorithm but I have not been able to go back work on this.
> - Did you find any heavy problems with the concept? E.g. I am not quite sure whether we
>   get proper results if memory is reused from the VM.
>   
The problem I found with current approach is that the locking scheme 
used to guard the shared memory. I believe it caused performance 
slowdown on the JVM side during the time of heavy jit activities. As for 
the memory re-use, the proposal does address that, but I have not see a 
condition where the memory is re-used and have not verify the 
implementation works correctly when it happens. It could be due to the 
nature of the Java applications I have used.
> - Any more activity going on at your place on this?
>   
Currently, there is no plan for me to make changes other than bug fix. 
If you have plan to extend the patch or create a new one I would be 
happy to share my experiences and work with you.

Jason