JDK-6923430 : G1: assert(res != 0,"This should have worked.")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs17
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2010-02-04
  • Updated: 2013-09-18
  • 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 7 Other
7Fixed hs21Fixed
Description
I've observed this assertion several times (on the sparc only), when humongous objects are allocated. Here are couple of them:
http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK6/ADHOC/VM/2010-02-03_03/vm/solaris-sparc/server/mixed/solaris-sparc_server_mixed_vm.gc.testlist/ResultDir/LargeHeap02
or 
http://sqeweb.sfbay.sun.com/nfs/tools/gtee/results/JDK6/ADHOC/VM/2010-02-02_02/vm/solaris-sparc/client/mixed/solaris-sparc_client_mixed_vm.gc.testlist/ResultDir/MemoryEater

This crash should be often reproduced. However test works a long time before crashes. 

The stack trace from hs_err:
;; Using jvm: "/net/sqenfs-1.sfbay/export1/jdk/vm/hsx/17/pit/b08/jdk7b81/fastdebug/solaris-sparc/jre/lib/sparc/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P1/B/230259.et151817/source/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:647), pid=4352, tid=19
#  Error: assert(res != 0,"This should have worked.")
#
# JRE version: 7.0-b80
# Java VM: Java HotSpot(TM) Server VM (17.0-b08-2010-01-22-230259.et151817.hs17b08-fastdebug mixed mode solaris-sparc )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x01267000):  JavaThread "Thread-1" [_thread_in_vm, id=19, stack(0x70180000,0x70200000)]

Stack: [0x70180000,0x70200000],  sp=0x701ff410,  free space=1fdfefad06ck
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x134c524];;  void VMError::report_and_die()+0x718
V  [libjvm.so+0x6f1d10];;  void report_assertion_failure(const char*,int,const char*)+0x70
V  [libjvm.so+0x7c731c];;  HeapWord*G1CollectedHeap::humongousObjAllocate(unsigned)+0x120
V  [libjvm.so+0x7c7b04];;  HeapWord*G1CollectedHeap::mem_allocate(unsigned,bool,bool,bool*)+0x248
V  [libjvm.so+0x2b8778];;  HeapWord*CollectedHeap::common_mem_allocate_noinit(unsigned,bool,Thread*)+0xd8
V  [libjvm.so+0x127a4c0];;  typeArrayOop typeArrayKlass::allocate(int,Thread*)+0x804
V  [libjvm.so+0xfb3600];;  typeArrayOop oopFactory::new_typeArray(BasicType,int,Thread*)+0x128
V  [libjvm.so+0x90ebb0];;  void InterpreterRuntime::newarray(JavaThread*,BasicType,int)+0x1bc
j  gc.huge.quicklook.memory.LargeHeap02.helper.create(I)V+1
j  gc.huge.quicklook.memory.LargeHeap02.helper.run()V+4
v  ~StubRoutines::call_stub
V  [libjvm.so+0x94594c];;  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x908
V  [libjvm.so+0x943e4c];;  void JavaCalls::call_virtual(JavaValue*,KlassHandle,symbolHandle,symbolHandle,JavaCallArguments*,Thread*)+0x404
V  [libjvm.so+0x943f5c];;  void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle,Thread*)+0xf4
V  [libjvm.so+0xaacaa0];;  void thread_entry(JavaThread*,Thread*)+0x318
V  [libjvm.so+0x1241cdc];;  void JavaThread::thread_main_inner()+0x228
V  [libjvm.so+0x1241a9c];;  void JavaThread::run()+0x534
V  [libjvm.so+0xfc9a28];;  java_start+0x1ac

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  gc.huge.quicklook.memory.LargeHeap02.helper.create(I)V+1
j  gc.huge.quicklook.memory.LargeHeap02.helper.run()V+4
v  ~StubRoutines::call_stub

Comments
EVALUATION Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp
02-02-2011

EVALUATION G1CollectedHeap::expand and G1CollectedHeap::shrink should return a status back to their callers which can then be used to throw an OOME instead of the assert that is currently occuring.
11-02-2010