This is the mail archive of the
mailing list for the systemtap project.
Re: Java VM support in SystemTap
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: "Scherbakov, Sergey V" <sergey dot v dot scherbakov at intel dot com>
- Cc: <systemtap at sourceware dot org>
- Date: 11 Jul 2006 12:13:13 -0400
- Subject: Re: Java VM support in SystemTap
- References: <3D8E84095C6A524A985B787423094E400C4E9E@mssmsx411>
> > 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*
- 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