1

I would like to be able to get the same ID that is being used in Java heap dumps (created via jmap or JMX, etc). This is to be able to identify the live object at the still running application versus an older memory snapshot (the heap dump) of the same app.

I have already tested a little and it is obvioulsy not the hashCode, neither the JDI unique ID (which you can see in your debuggers).

From checking the code in the sun.jvm.hotspot.utilities I assume it is the objects address in memory. But also my tests with sun.misc.Unsafe didn't lead to the same id value as used in the heap dumps. (see here for some Unsafe explanation: http://zeroturnaround.com/rebellabs/dangerous-code-how-to-be-unsafe-with-java-classes-objects-in-memory/)

Any ideas? Thanks :) !

Haasip Satang
  • 457
  • 3
  • 17
  • Does the object (or any of it's super-objects) override hashCode? If so, you might luck out with [`System.identityHashCode()`](http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#identityHashCode%28java.lang.Object%29) – blazetopher Jun 03 '15 at 20:03
  • Or could it possibly be as simple as needing the hex value of the hashCode? `Integer.toHexString(obj.hashCode())`... – blazetopher Jun 03 '15 at 20:07
  • Thanks for your comment but no, as I said it's unfortunately not the hashCode. Also not System.identiyHashCode (which is the same as the normal object hashCode in case it is not overridden). And no, hex or decimal doesn't matter. In the end it is the same value, right? Most heap dump analyzers tend to display the value as hex. The value is a simple long value in my case (probably because of the 64bit jvm). – Haasip Satang Jun 04 '15 at 02:35

1 Answers1

3

There are two different ways to create a heap dump:

  1. from inside JVM process using Dynamic Attach Mechanism (jmap does so), or
  2. from the external process using Serviceability Agent (jmap -F)

In both cases the object ID in the heap dump is the memory address of an object at the moment of creating the dump. Here is the relevant HotSpot source code: [1] and [2].

However, this object ID is meaningless outside the dump file, because objects can move in memory during Garbage Collection.

The other problem is that it's difficult (or even impossible) to get a reliable address of a Java object from within Java application - again, because the objects may move along the heap and because the representation of object references can vary between different architectures, environments and JVM options, e.g. depending on heap size, UseCompressedOops etc. Here is an example of getting an object address from within Java application, but this is not guaranteed to work on all JVM versions.

apangin
  • 92,924
  • 10
  • 193
  • 247