oop, Handle, and hash key

[Tom Rodriguez]

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