During testing for 6659663 I came across failures that look like this (they were discovered during heap verification before GC):
Field 0xdb97e138 of live obj 0xd35ff238 points to dead obj 0xd35ff234.
Live obj:
[Ljava.util.Date;
- klass: 'java/util/Date'[]
- length: 5
- 0 : a 'java/util/Date'
- 1 : a 'java/util/Date'
- 2 : a 'java/util/Date'
- 3 : a 'java/util/Date'
- 4 : a 'java/util/Date'
Bad referent:
java.util.Date
- klass: 'java/util/Date'
fields:
- private transient 'fastTime' 'J' @8
- private transient 'cdate' 'Lsun/util/calendar/BaseCalendar$Date;' @16
Thse are not the "standard" missing remset entry failures. They actually indicate that a live object is pointing to a garbage one. I ran with -XX:+G1VerifyConcMark and I get the same failure at the end of marking (marking verification happens at the end of cleanup).
I can reproduce this issue relatively easily but with the heavy instrumentation I have added to the VM when investigating 6659663. I went back to my error logs for previous instances of this failure and I can only find one (but it happens very easily with the added instrumentation).
I have reproduced it with jbb2005 on Niagara and Tigerton.
Field 0xdb97e138 of live obj 0xd35ff238 points to dead obj 0xd35ff234.
Live obj:
[Ljava.util.Date;
- klass: 'java/util/Date'[]
- length: 5
- 0 : a 'java/util/Date'
- 1 : a 'java/util/Date'
- 2 : a 'java/util/Date'
- 3 : a 'java/util/Date'
- 4 : a 'java/util/Date'
Bad referent:
java.util.Date
- klass: 'java/util/Date'
fields:
- private transient 'fastTime' 'J' @8
- private transient 'cdate' 'Lsun/util/calendar/BaseCalendar$Date;' @16
Thse are not the "standard" missing remset entry failures. They actually indicate that a live object is pointing to a garbage one. I ran with -XX:+G1VerifyConcMark and I get the same failure at the end of marking (marking verification happens at the end of cleanup).
I can reproduce this issue relatively easily but with the heavy instrumentation I have added to the VM when investigating 6659663. I went back to my error logs for previous instances of this failure and I can only find one (but it happens very easily with the added instrumentation).
I have reproduced it with jbb2005 on Niagara and Tigerton.
- duplicates
-
JDK-6900941 G1: VerifyDuring failure
-
- Closed
-
- relates to
-
JDK-6909756 G1: guarantee(!G1CollectedHeap::heap()->mark_in_progress(),"Precondition.")
-
- Resolved
-
-
JDK-6940310 G1: MT-unsafe calls to CM::region_stack_push() / CM::region_stack_pop()
-
- Resolved
-
-
JDK-6935821 G1: threads created during marking do not active their SATB queues
-
- Closed
-