How to uniquely distinguish Java's object instance

Question

I'm currently building a native JVMTI agent for Java 1.7. The problem is that I need to index some data regarding specific Java's object instances. So my question is can I use jobject type's value as an object's instance ID to retrieve my indexed data ?

I have look for any information about what is the semantics of jobject type. Is it a pointer on Object's memory location ? Is it a stack pointer address ? Is it an address to a JVM's internal structure ? So I can't figure out if jobject's value is unique and immutable along Java object's life.

Thanks for your help.

edit

According to JNI's specifications found here, jobject seems to be a pointer on Object's instance.

Garald

what have you done so far and what is the exact type of information you are trying to obtain and index or retrieve based on what you have obtained? – Loci

May be similar: #910343 – Seniority

In fact, my question is about a JVMTI agent written in C. I want to use Object's instance as primary keys for caching purpose (implemented as an hash map or a red-black-tree for example) For now I'm tagging each object with a unique id thanks to SetTag & GetTag functions. – Garald

Answer 1

When you say you "jobject type's value" I am guessing you mean the value returned by the toString. If you look at the java doc It states that:

The toString method for class Object returns a string consisting of the name of the class of which the object is an instance, the at-sign character `@', and the unsigned hexadecimal representation of the hash code of the object. In other words, this method returns a string equal to the value of:

    getClass().getName() + '@' + Integer.toHexString(hashCode())

And if you look at the Java doc for the hashCode method it states:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer

and also

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

Update: Response to Ryan's comment: System.identityHashCode will get you the original hash code even if the hashcode method is overridden. However, like comments note its not really unique.

So I guess the answer to your questions is yes its immutable and its very very likely to be unique but you should read the docs or source code for your JVM.

Articulate

HashCode is unique to each object. However, it is supposed to be overridden if you override equals, such that it will be the same as any other object that is equivalent by equals. – Seniority

@Ryan No it certainly is not always unique. Quite obviously so: You'll have a hard time to guarantee a unique identifier using 32bits on a 64bit system.. – Unexpressive

Additionally the equals/hashcode contract says that 2 equal objects have the same hash code. So if two objects were semantically equal, their hashcodes should be the same. Two unequal objects may have the same hashcode though, so System.identityHashCode (or any hashcode implementation) cannot guarantee uniqueness. – Lulululuabourg

I don't think the Objects of type "Object" can be semantically equal. Their derived classes can be but the System.identityHashCode will get around that. Still Voo's comment about 64bit addresses is the real reason why uniqueness will be broken. – Articulate

Yeah I know about Haschode and identityHashCode but as previous comments highlights it, returned values are not guaranteed to be unique – Garald

Answer 2

At least in HotSpot, jobject is indeed a pointer to an object location, that is, dereferencing it will give you an address that is unique for each object, which is half of the "unique and immutable identity" that you ask about. The problem is that the address can change during garbage collection, since HotSpot can move objects around.

The JVMTI GetTag and SetTag functions internally use a hash table from the object location to the tag. HotSpot updates this hash table whenever objects are moved around, something which you cannot easily replicate from the position of a JVMTI agent. Assigning your own unique identity values with the tags, as you say you are already doing, is probably the only way to go here.

Insensitive