RE: Java VM support in SystemTap

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

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