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
next 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).