How to retrieve the receiver object of method call

[Tom Rodriguez]

Instead of jumping through those hoops just handle it like we handle _exception_oop.  Then you don't need to do the extra handlizing.

tom

On Apr 8, 2010, at 6:43 PM, Peng Du wrote:

> 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
> 
>