This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Java VM support in SystemTap
- From: "Scherbakov, Sergey V" <sergey dot v dot scherbakov at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sourceware dot org>
- Date: Thu, 13 Jul 2006 13:49:52 +0400
- Subject: RE: Java VM support in SystemTap
Frank,
We took one-day timeout to read about 'plan B' and discuss your really
useful ideas/comments between us.
Actually, in beginning of our researches we were thinking about similar
model. We are planned to set a breakpoint to some stab inside JVMTI/PI
agent and then use kernel probe scenario. Unfortunately in this case we
have a lot of almost undecidable issues.
I guess the main issue that in case of kernel/user probe we know
address, we can unwind stack etc., on other hand (JVM) we have only
event of some class (MethodEnter for instance). We even cannot set a
breakpoint in JIT-ed function (we know its address), because it is
possible to have more that one JIT-ed variant, but VM can choose to use
interpreter. Sure we can generate C/C++ stub corresponding every method
of interest, but it is really difficult (almost impossible in case of
wildcards usage).
Frank Ch. Eigler wrote:
> 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.
The following is a quotation from our internal discussion:
-- The optional data needed [$obj->obj2->field] is defined at script
start -- time. This could in theory be passed thru stpd to the VM
agent at
-- configuration time. [i.e., the "RequestOptionalData" could all be
set -- up ahead of time...]
-- e.g.
-- p=RegisterProbe("java/lang/...",enter);
-- RequestOptionalData(p, PARAMETER1,...);
--
-- Then when the event occurs, the VM agent bundles the event with the
-- registeredOptionalData and sends it as a packet to stpd who forwards
to -- kernel. The kernel component won't need to request additional
stuff at -- run time.
Thanks,
Sergey