RE: Java VM support in SystemTap

["Scherbakov, Sergey V" <sergey dot v dot scherbakov at intel dot com>]

Frank,

I'm coauthor of that proposal. First of all, thanks for the quick
evaluation. Please see my question/comments inlined.


-----Original Message-----
From: fche@redhat.com [mailto:fche@redhat.com] 


> The key trick is the notion of using stpd as an intermediary between
> user-space event sources (in this case, JVM instrumentation hooks
> talking to a specialized systemtap-bundled supervisor program) and
> normal kernel-space probe handlers.

Is it means that we really can use stpd as gate between VM and
kernel-space probe handlers? I'm asking because our ideas based not on
deep knowledge of SystemTap but mostly on common sense. 

> This is interesting because it suggests a mechanism for general
> user-space probing, where instead of using JVM[TPD]I APIs, a specially
> built user-space supervisor program could use ptrace or utrace or
> whatever to manage a non-JVM program.  It could relay this occurrence
> to kernel-side probe handlers via stpd.

If you think, it is interesting not only for using with Java VM may be
it is good idea to extend/generalize that communication interface?

> A consequence of this type of approach is to suffer multiple context
> switches per probe hit.  Further, if these supervisor programs are
> general (not parametrized for the particular probe script), then the
> quantity of contextual data would be strictly limited.  That's
> because, for several reasons, all plausible $target data would need to
> be collected at probe-hit time, and packaged up in the first packet
> toward stpd to relay to kernel-space.  (Explicit request/reply type
> interaction from the kernel probe handlers is not going to work.)

Yes, agree. It is an issue. It is why in case of VM we propose to use
special command 'RequestOptionalData' to describe expected data and
avoid unnecessary context switches.

Thanks
  Sergey