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