United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6923430 G1: assert(res != 0,"This should have worked.")
JDK-6923430 : G1: assert(res != 0,"This should have worked.")

Details
Type:
Bug
Submit Date:
2010-02-04
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs17
Fixed Versions:
hs21 (b02)

Related Reports
Backport:

Sub Tasks

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

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.
                                     
2010-02-11
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
                                     
2011-02-02



Hardware and Software, Engineered to Work Together