public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Scherbakov, Sergey V" <sergey.v.scherbakov@intel.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <systemtap@sourceware.org>
Subject: RE: Java VM support in SystemTap
Date: Thu, 13 Jul 2006 09:51:00 -0000	[thread overview]
Message-ID: <3D8E84095C6A524A985B787423094E4010B7BF@mssmsx411> (raw)

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

             reply	other threads:[~2006-07-13  9:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-13  9:51 Scherbakov, Sergey V [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-07-10 22:09 Scherbakov, Sergey V
2006-07-11 16:13 ` Frank Ch. Eigler
2006-07-07 19:54 Danilov, Oleg V
2006-07-07 21:25 ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D8E84095C6A524A985B787423094E4010B7BF@mssmsx411 \
    --to=sergey.v.scherbakov@intel.com \
    --cc=fche@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).