RFR: JDK-8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump

Andreas Eriksson andreas.eriksson at oracle.com
Fri Oct 30 14:03:29 UTC 2015


Hi,

Please review this change to heap dump logic.
Including runtime list, since this is related to class loading.

Bug:
JDK-8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify 
the dump
https://bugs.openjdk.java.net/browse/JDK-8134030

Webrev: http://cr.openjdk.java.net/~aeriksso/8134030/webrev.00/

A heap dump can occur at a point where an InstanceKlass doesn't have a 
Java class mirror yet.
To avoid a crash because of this JDK-8131600 [1] excluded classes that 
are not linked yet from the dump.

The problem here is that since a class that has been loaded is already 
exposed to the Java side, another class can have a reference to the 
excluded class.
So, if it has been *loaded* but not *linked* it will be excluded, but 
can still be referenced by other classes in the dump.
This gives the following warning in HeapDumpTest:
WARNING: Failed to resolve object id 0x6c003d348 [...].

This fix changes heapDumper.cpp to only exclude classes that are not yet 
loaded instead.

I'd like confirmation on this from someone who knows more about loaded 
vs linked, but I think that this is correct:
When a class has been loaded, we are guaranteed that a Java class mirror 
is setup, so the crash seen in JDK-8131600 still cannot happen.
This seems to be confirmed by the manual reproducer from JDK-8131600, 
which still succeeds with this fix.

Also in this change is the re-addition of the actual heap dump 
verification call in HeapDumpTest, which was accidentally removed when 
the test was re-factored.

Regards,
Andreas

[1]: https://bugs.openjdk.java.net/browse/JDK-8131600


More information about the hotspot-runtime-dev mailing list