[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RFR: JDK-8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump
From:       Andreas Eriksson <andreas.eriksson () oracle ! com>
Date:       2015-10-30 14:03:29
Message-ID: 563378B1.6080607 () oracle ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]