JDK-6627983 : G1: Bad oop deference during marking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u14,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris
  • CPU: x86,sparc
  • Submitted: 2007-11-09
  • Updated: 2012-11-02
  • Resolved: 2011-04-25
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 7 Other
7Fixed hs21Fixed
Related Reports
Duplicate :  
JDK-6850600 - G1: After changing to the experimental G1 garbage collector, the JVM segfaults.
Relates :  
JDK-6899780 - EXCEPTION_ACCESS_VIOLATION in size_given_klass
Description
A bad oop is hit during marking:

  [7] report_assertion_failure(file_name = 0xfe96e054 "/net/129.159.127.138/.1/root/work/hotspot/g1_baseline/src/share/vm/oops/klass.hpp", line_no = 421, message = 0xfe96e0a6 "assert(l2esz <= LogBitsPerLong,"sanity")"), line 173 in "debug.cpp"
  [8] Klass::layout_helper_log2_element_size(lh = -1380270406), line 421 in "klass.hpp"
  [9] oopDesc::size_given_klass(this = 0xbaadbabe, klass = 0xcb71bab5), line 175 in "oop.inline.hpp"
  [10] oopDesc::size(this = 0xbaadbabe), line 219 in "oop.inline.hpp"
  [11] CMTask::scan_object(this = 0x16ce48, obj = 0xbaadbabe), line 982 in "concurrentMark.hpp"
  [12] CMTask::drain_local_queue(this = 0x16ce48, partially = true), line 3203 in "concurrentMark.cpp"
  [13] CMTask::do_marking_step(this = 0x16ce48, time_target_ms = 10.0), line 3619 in "concurrentMark.cpp"
  [14] CMConcurrentMarkingTask::work(this = 0xb577f9f8, worker_i = 1), line 1080 in "concurrentMark.cpp"
  [15] GangWorker::loop(this = 0x1ce400), line 281 in "workgroup.cpp"
  [16] GangWorker::run(this = 0x1ce400), line 197 in "workgroup.cpp"
  [17] java_start(thread_addr = 0x1ce400), line 1010 in "os_solaris.cpp"

Observed on Solaris-SPARC running GCBasher.
Command line: java -server -XX:+UseG1GC -XX:+PrintGCDetails -XX:+ShowMessageBoxOnError -jar GCBasher.jar -time:300000
Seen again with

javasoft.sqe.tests.lang.clss146.clss14601.clss14601

on solaris-sparc

http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK7/NIGHTLY/VM/2010-06-23/GC_Baseline-Xconc/runThese/solaris-sparc/server/mixed/solaris-sparc_server_mixed_quick_1296827CE37/log
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0ac769a57c64
02-03-2011
EVALUATION This is caused by the use of array copy code to initialize an oop. The array copy code calls the pre-barrier using the value from the unitialized oop. Either the use of array copy for initialization has to have a special version with no pre-barrier or the optimization needs to be turned off in the presence of a pre-barrier.
03-12-2007