How to retrieve the receiver object of method call

Peng Du imdupeng at gmail.com
Thu Apr 8 18:43:58 PDT 2010


David and Tom,

I ended up allocating a JNI local handle in JavaThread::oops_do() to
preserve
that field and restore it in the end. It worked as expected. I only cache
receiver
inside compiled methods since it's easy to get receiver from an interpreted
caller frame.

You guys saved my day! Many thanks!

-Peng

On Thu, Apr 8, 2010 at 8:21 PM, Tom Rodriguez <tom.rodriguez at oracle.com>wrote:

>
> On Apr 8, 2010, at 5:50 PM, David Holmes wrote:
>
> > Peng Du said the following on 04/09/10 07:27:
> >> I guess my current solution is not viable. The reason why I want to
> >> do it ad-hoc is that there are some events that will happen in the
> >> entry of a method that I have previously setup. They are not at the
> >> call sites. But, my analysis is on a per instance basis since each
> >> instance carries some payload I allocated.
> >> I used to cache the receiver objects to JavaThread when I see
> >> _invokeXXX bytecodes. But when GC comes, it seems it would move this
> >> object away and cause SIGSEGV when later I try to retrieve it.
> >> Besides, caching the receiver for every Java calls is not efficient I
> >> guess.
> >
> > Use a Handle to protect the object reference. May not be efficient but
> should solve your SEGV problems.
>
> I think he'd just want to add the field to the oops_do for thread.
>
> tom
>
> >
> > David Holmes
> >
> >> Can you suggest some other approach? I can explain more what I am
> >> doing if that's helps.
> >> Thanks, Tom!
> >> -Peng
> >> On 04/08/2010 04:19 PM, Tom Rodriguez wrote:
> >>> Well, you kind of have to look at the compiled frame as a set of
> vframes to get access to the locals unless you want to build it all
> >>> yourself.  Basically you'd grab the PcDesc for the pc and look at
> >>> the debug info to find the mapping from local 0 of the root of the
> >>> compiled frame to some register or stack slot.  This requires
> >>> having a proper RegisterMap and being at a pc that has debug info,
> >>> which is pretty much only call sites.  If you want to be able to
> >>> get it at arbitrary pcs then you are out of luck.
> >>> Why can't you just arrange to grab the value you need directly
> >>> instead of trying to get at it introspectively?
> >>> tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100408/e4692fee/attachment.html 


More information about the hotspot-dev mailing list