How to retrieve the receiver object of method call

Tom Rodriguez tom.rodriguez at
Thu Apr 8 18:21:53 PDT 2010

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.


> 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

More information about the hotspot-dev mailing list