JDK-6841831 : G1: assert(contains_reference(from),"We just added it!") fires
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-05-15
  • Updated: 2010-04-04
  • Resolved: 2009-06-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Description
During testing we've hit 

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
(/home/jc234399/ws/6819077c/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp:599),
pid=241, tid=8
# Error: assert(contains_reference(from),"We just added it!")
#
# JRE version: 7.0-b58
# Java VM: OpenJDK Server VM (16.0-b02-internal-jvmg mixed mode
solaris-x86 )
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

a couple of times.

John Cuthbertson hit it with the following

"The test case was again SPECjbb2005, 32 bit JVM, 2Gb of heap, 1s/4c x86 Sun 24 running solaris 10. According to the back trace we're updating a Rset for a heap region. I've seen this twice so far out of around 50 runs (overnight). "
I also hit it by running specjbb2000 inside the GC test suite. The build was fastedbug / server / amd64 running on Solaris.
Comments
EVALUATION See main CR
17-06-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/215f81b4d9b3
18-05-2009
EVALUATION The crash happens because mutator threads can claim a worker id that would intersect with a worker ids of the concurrent refinement threads. The fix would be to make sure that the set of ids used by the mutator threads is disjoint from the set used an the refinement threads.
16-05-2009
EVALUATION One possible explanation for this is that Igor's parallel concurrent refinement (CR6484957) is uncovering a race that we have in RSet updating.
15-05-2009