Re: Java VM support in SystemTap

[fche at redhat dot com (Frank Ch. Eigler)]

"Danilov, Oleg V" <oleg.v.danilov@intel.com> writes:

> Inspired by the SUN DTrace ability to provide insight information
> about running java applications we think it makes sense to add this
> ability to the SystemTap as well. [...]

It's an interesting bunch of ideas.  It's impressive that you worked
stuff out all the way through possible message formats and probe point
syntax, which is useful analysis regardless of ultimate
implementation.

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.

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.

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

- FChE