RFR: 8038925: Java with G1 crashes in dump_instance_fields using jmap or jcmd without fullgc
Andreas Eriksson
andreas.eriksson at oracle.com
Wed May 21 10:12:59 UTC 2014
Hi Bengt, thanks for looking at this.
I agree that verifying that no full GC has happened would be good.
One thing I see as problematic though, is what to do if a full GC has
happened.
Should I make the test fail? Or is there some way to signal that the
test was inconclusive / couldn't finish?
Regards,
Andreas
On 2014-05-21 11:55, Bengt Rutisson wrote:
>
> Hi Andreas,
>
> The fix looks good.
>
> One comment about the test. It does not verify that no full GC
> happens. The way the test is set up I guess that should not happen and
> I am not sure it is worth the effort to add a check for it. Just
> wanted to mention it if you want to make test more resilient to future
> changes in the JVM that for some reason can trigger a full GC for this
> test.
>
> I'm fine with leaving the test as it is.
>
> Thanks,
> Bengt
>
>
> On 5/20/14 4:26 PM, Andreas Eriksson wrote:
>> Hi,
>>
>> Could I have a review for this G1 jdk7 only fix please?
>> (There is a related problem in jdk8 and jdk9, where an assert can
>> fail because of this problem. I have logged another bug for this.)
>>
>> Description:
>> Due to the marking cleanup reclaiming empty regions, and having stale
>> references a crash can occur when doing a heap dump.
>> The code tries to do an is_klass check on the object, which crashes
>> the VM.
>> The fix is to add an is_perm check before doing the check, since
>> is_perm will do a bounds check on the oop and if it's in the perm gen
>> we know it's safe to look at it since G1 only ever does full
>> compactions of the perm gen.
>>
>> For more information, and a more in-depth analysis, please see the
>> jira bug.
>>
>> http://cr.openjdk.java.net/~aeriksso/8038925/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8038925
>>
>> Regards,
>> Andreas
>
More information about the hotspot-gc-dev
mailing list