RE: [RFC]-Approaches to user space probes

["Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>]

>anil.s.keshavamurthy wrote:
>
>> [...]
>> Sure, their is some advantange in 4, but the thing we need to see
>> is whether this apporach suits probing different kinds of 
>> application(mainly java apps).
>
>Could you explain why you think Java would be harder to instrument
>with kernel-space probes?  We may opt to compose user-kprobes along
>the lines of #4, and static instrumentation (a libmudflap.so
>containing hooks for language interpreters to hook up to and pass
>event parameters).

I am not an expert in Java or Java probes, but before we lock down this
approach
I am suggesting that if possible we get feedback from JVM gurus too.


>That is not such a big problem.  Should such an unfortunate timing
>glitch occur, the system would report a missed probe.  The user could
>then try again.

Frank, having a counter to count the missed probe does not solve the
problem here.
The issue here is that your function entry probe handler gets fired and
there are chances that
the corresponding function return probe hander might not be called and
rp->nmissed++ will
do no good. 
In other words we should not see rp->nmissed > 0, 
however it is okay to for rp->kp.nmissed > 0.

-Anil