JDK-6696264 : assert("narrow oop can never be zero") for GCBasher & ParNewGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs13
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-04-30
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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
6u14Fixed 7Fixed hs13Fixed
Description
Very sporatic GCBasher bugs with this assert.
eval C:/jprt/temp/P1/T/192955.rasbold/testproduct/windows_x64_5.2-fastdebug/bin/java
  -server -Xmx128M -XX:+UseParNewGC -jar GCBasher.jar -time:300000 )
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\oop.inline.hpp:147
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\jprt\temp\P1\B\192955.rasbold\source\src\share\vm\oops\oop.inline.hpp:147),
  pid=2628, tid=3224
#  Error: assert(!is_null(v),"narrow oop value can never be zero")
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM
  (12.0-b02-2008-04-22-192955.rasbold.hotspot-comp-clean-fastdebug mixed mode
  windows-amd64 compressed oops)
# An error report file with more information is saved as:
# C:\jprt\products\P1\GCBasher\hs_err_pid2628.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
VM option '+UseParNewGC'

Decoded hs_err file attached.
Comments
EVALUATION Fixed 6696264: assert("narrow oop can never be zero") for GCBasher & ParNewGC The set_klass() call and store_klass() in the assembler were zeroing the 32 bit gap left by the compressed _klass field in order to initialize it. There are other set_klass() calls in the VM that want to keep the values filled into the gap. When the gap has the _length field for arrays, overwriting it messes up size computation for GC. This can result in a "p is not a block start" assertion, which was hidden by this "narrow oop can never be zero". Pulled out the set_klass() changes out of the CMS+compressed oops workspace to fix this bug. Only zero the gap when initializing. Fix verified: n I couldn't veriy this because I could never get it to fail for me in jprt. Now look for a 'p is not a block start' assertion to see if this didn't fix it. Tested by: GCBasher ParNewGC, my sanity nsk testlist with ParNewGC webrev: http://webrev.invokedynamic.info/coleenp/6696264 Reviewed by: kvn, ysr, jrose
02-06-2008