Re: Java VM support in SystemTap

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

sergey.v.scherbakov wrote:

> [...]
> > 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? [...]

It sounds like a fit, at least in theory.  There are probably some
other possibilities also (see below).

> > [...]  Further, if these supervisor programs are general (not
> > parametrized for the particular probe script), then the quantity
> > of contextual data would be strictly limited.  [...]
>
> 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.

My point is that if the "optional data" is a function of the probe
script (say, the list of actual $obj->obj2->field expressions used),
and if this list is not available ahead of time to the user-side
intermediary programs, then the kernel-side probes won't be able to
get at them at all.  The kernel-side probe handlers cannot practically
query them during hit time.


This concern leads me to speculate about another possible
implementation technique, one that does not use stpd nor a generic
unparametrized JVM interface process.  That is to have the translator
map JVM probes to a custom user-space program that includes
- the JVMDI etc. logic needed to hook up identified JVMs
- the probe handlers proper
- an alternative run-time library that can operate in user-space
If in fact such a JVMDI client program can be dynamically loaded into
the JVM rather than run as an external process, so much the better.

In order to enable a single systemtap script to probe both kernel and
JVM space in this model, they would have to be able to *share memory*
such as
- systemtap script-level global variables
- and their locks!
- supervisory state such as error_count
Of course this would have to be done in a secure and safe manner, which
would require the run-time code to be more paranoid.

Perhaps the execution model is obvious from the above and is similar
to plan B: <http://sourceware.org/ml/systemtap/2006-q2/msg00570.html>.
In particular, it may offer the following advantages over the
generic-intermediary + stpd + kernel-space probe handlers proposal:
- faster performance because of absence of context switching
- full context information available
- simpler in one way (inter-process communication), though
  more complex in another (possible need to share live kernel
  systemtap data)

- FChE