oop, Handle, and hash key

[Peng Du]

Tom and Ramki,

Thanks for the pointers, according to which there is not easy way for such
things. I guess have to
to revise my design and come up with new protocols. Otherwise, I will try
Ramki's solution. I might
follow up when I meet further problems.

Thanks, guys.


On Mon, Mar 1, 2010 at 6:03 PM, Y. Srinivas Ramakrishna <
Y.S.Ramakrishna at sun.com> wrote:

> Peng Du wrote:
>
>> Thanks, Tom
>>
>> Unfortunately, I need to track the method invocation per object basis.
>> For example, if method hello() in class Foo is called, I need to know
>> which receiver (instance) it is called on. Then I can relate the call to
>> the value I kept in my hash table. So, I really need an persistent ID to
>> the object, not the method.
>> Any idea how that can be done?
>>
>
> Use the identity hash as a key and maintain a weak ref to the object along
> with yr state
> information for that entry. The weak ref will be updated by GC when an
> object moves and
> cleared when the object dies and is reclaimed by GC. Then use the identity
> hashcode to
> access yr object and use the object address to compare against the weak ref
> value in the
> table to locate the corresponding entry. This is somewhat cumbersome but
> should work. I think.
>
> -- ramki
>
>
>
>> Thanks
>>
>>  On Mon, 2010-03-01 at 15:38 -0800, Tom Rodriguez wrote:
>>
>>> You can't use the address of any kind of handle for your hash since
>>> there's no way to reverse that mapping.  You can always allocate a handle of
>>> some kind for an arbitrary object but you can't look up a unique handle from
>>> the oop without having some other key to hash on.  You could use identity
>>> hash code since that is persistent but I'm not sure I would use that with
>>> perm objects since they aren't really Java objects.  If you are tracking
>>> methodOops only then you can build hash key from the method name, klass and
>>> signature since those are stable or you might able to be able to use the
>>> jmethodID which is a system managed unique weak global reference to the
>>> methodOops.  jmethodID is just a type alias for jobject so it's a pointer
>>> and you could use that as your hash.
>>>
>>> tom
>>>
>>> On Mar 1, 2010, at 3:15 PM, Peng Du wrote:
>>>
>>>  Ramki,
>>>> First, I appreciate your quick follow-ups. Second, let me tell you what
>>>> I want to do. Say I want to keep track of method calls of some Java
>>>> objects during runtime. I have written some handlers, which will be
>>>> invoked by the hooks in the interpreter. Now I need the reference to the
>>>> receiver object of the method as a key to the hash table to store some
>>>> state information. Given the volatile nature of the oops, I have to use
>>>> something else as the hash key. Then came the idea of Handle.
>>>> I just read the code of JNIHandles::make_global(), which always allocate
>>>> fresh handles upon requested. So, I guess you are right in the 2nd post.
>>>> I can use it to identify the objects.
>>>> Given the scenario, what do you think is the best solution?
>>>> Thank you again!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote:
>>>>
>>>>> On further thought this may or may not work for you
>>>>> because of "aliasing"... The same oop o may have more
>>>>> than one JNI weak reference to it (just as might have
>>>>> been the case for your Handle idea below). So while
>>>>> JNI weak refs will have the property that
>>>>> no two oops will have the same key, it is possible that
>>>>> the same oop may be referred to by several distinct
>>>>> handles and thus the key is not a canonical identifier
>>>>> for an oop either.
>>>>>
>>>>> So i guess it really depends on how you were going to
>>>>> use your hashtable, and JNI weak refs may not work either.
>>>>>
>>>>> Sorry for the hasty earlier response.
>>>>> -- ramki
>>>>>
>>>>> Peng Du wrote:
>>>>>
>>>>>> Hi, ramki
>>>>>>
>>>>>> Thanks for your quick reply! You're right about what I want. weak
>>>>>> global
>>>>>> JNI handle seems a good solution. I guess later I have to put some
>>>>>> hooks
>>>>>> into GC to do the reclamation. Otherwise, I need a periodic thread to
>>>>>> do
>>>>>> the housekeeping.
>>>>>> In case I have further questions, I will post back. Thanks!
>>>>>>
>>>>>>
>>>>>> On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote:
>>>>>>
>>>>>>> Hi Peng --
>>>>>>>
>>>>>>> Peng Du wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I need unique and persistent identifiers to Java objects as keys to
>>>>>>>> a
>>>>>>>> hash table. However, I couldn't find an object_id kind routine. And
>>>>>>>> I am
>>>>>>>> not sure if identity_hash() guarantees uniqueness. So, I figured I
>>>>>>>> can
>>>>>>>> use the address of a Handle of an oop for this purpose, e.g.
>>>>>>>> oop o;
>>>>>>>> ...
>>>>>>>> Handle h(o);
>>>>>>>> ...
>>>>>>>> hash.put(h->raw_value(), xx);
>>>>>>>>
>>>>>>>>
>>>>>>>> Considering there is no HandleMark around the code, does this work?
>>>>>>>> If
>>>>>>>> yes, would GC reclaim the handle if the associated object (oop)
>>>>>>>> dies?
>>>>>>>>
>>>>>>> When would you release the handle? What you seem to need is
>>>>>>> basically a weak global JNI handle. JVM internal Handle's will
>>>>>>> not work in your case for the reasons you gave above -- you do
>>>>>>> not have a HandleMark, so the lifetime of your handle is determined
>>>>>>> by some unknown HandleMark in which your code is nesting above, and
>>>>>>> so your handle will be destructed at some unspecified point depending
>>>>>>> upon context. Worse, as long as your handle is in scope, the
>>>>>>> object being referred to will be kept alive so you'll see
>>>>>>> this as leaks in the java heap. I think (if i understood yr
>>>>>>> use correctly) that what you really need is a weak global JNI ref
>>>>>>> to use as the key into your hash table. And you'd need to
>>>>>>> periodically
>>>>>>> remove the tombstone entries for the dead and reclaimed oop's (the
>>>>>>> weak refs will not keep the oops alive which is exactly the
>>>>>>> behaviour i think you want?).
>>>>>>>
>>>>>>> -- ramki
>>>>>>>
>>>>>>>  Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100301/693f4210/attachment.html