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.
According to JNI's specifications found here, jobject seems to be a pointer on Object's instance.
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
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.
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.