United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7086533 G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835
7086533 : G1: assert(!_g1->is_obj_dead(obj)): We should not be preserving dead objs: g1CollectedHeap.cpp:3835

Details
Type:
Bug
Submit Date:
2011-09-02
Status:
Closed
Updated Date:
2012-12-05
Project Name:
JDK
Resolved Date:
2012-01-23
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs23

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
vm/gc/concurrent/lp60yp0rp70mr30st300t1
gc/memory/UniThread/Linear4
gc/memory/UniThread/Circular4
http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2011-08-31/G1_GC_Baseline/vm/windows-i586/server/mixed/windows-i586_vm_server_mixed_vm.gc.testlist/analysis.html

http://sqeweb.us.oracle.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2011-08-30/G1_GC_Baseline/vm/windows-i586/client/mixed/windows-i586_vm_client_mixed_vm.gc.testlist/analysis.html

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\temp\jprt\P1\172141.jc234399\source\src\share\vm\gc_implementation\g1\g1CollectedHeap.cpp:3835), pid=19140, tid=17824
#  assert(!_g1->is_obj_dead(obj)) failed: We should not be preserving dead objs.
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) Server VM (22.0-b02-internal-201108311721.jc234399.hotspot-fastdebug mixed mode windows-x86 )
# Core dump written. Default location: c:\local\54630.JDK7.NIGHTLY.VM+windows-i586_vm_server_mixed_vm.gc.testlist\results\ResultDir\lp60yp0rp70mr30st300t1\hs_err_pid19140.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

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

Current thread (0x2bcb7800):  VMThread [stack: 0x2bdc0000,0x2be10000] [id=17824]

Stack: [0x2bdc0000,0x2be10000],  sp=0x2be0f594,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
Warning: This error log is *not* generated by the following JVM:
           C:/local/common/jdk/baseline/windows-i586/jre/bin/server/jvm.dll
         JVM symbol lookup may be incorrect.
         Please use --jvm=<path/to/jvm> to point to the correct JVM.

V  [jvm.dll+0x2684c1];;  ?report_and_die@VMError@@QAEXXZ+0x581
V  [jvm.dll+0x25f4a5];;  ?report_vm_error@@YAXPBDH00@Z+0x45
V  [jvm.dll+0x375c0e];;  ?do_object@RemoveSelfPointerClosure@@UAEXPAVoopDesc@@@Z+0xae
V  [jvm.dll+0xce07a];;  ?object_iterate_from@ContiguousSpace@@UAEXVWaterMark@@PAVObjectClosure@@@Z+0x4a
V  [jvm.dll+0xcc266];;  ?object_iterate@ContiguousSpace@@UAEXPAVObjectClosure@@@Z+0x26
V  [jvm.dll+0x376cd4];;  ?remove_self_forwarding_pointers@G1CollectedHeap@@IAEXXZ+0x1a4
V  [jvm.dll+0x379aea];;  ?evacuate_collection_set@G1CollectedHeap@@IAEXXZ+0x24a
V  [jvm.dll+0x37a2d7];;  ?do_collection_pause_at_safepoint@G1CollectedHeap@@IAE_NN@Z+0x677
V  [jvm.dll+0x38f1dd];;  ?doit@VM_G1IncCollectionPause@@UAEXXZ+0xdd
V  [jvm.dll+0x242e1d];;  ?evaluate@VM_Operation@@QAEXXZ+0x3d
V  [jvm.dll+0x241ac4];;  ?evaluate_operation@VMThread@@AAEXPAVVM_Operation@@@Z+0x54
V  [jvm.dll+0x241ee0];;  ?loop@VMThread@@QAEXXZ+0x360
V  [jvm.dll+0x24272e];;  ?run@VMThread@@UAEXXZ+0xae
V  [jvm.dll+0x27ced4];;  ?java_start@@YGIPAVThread@@@Z+0xc4
C  [msvcr100.dll+0x5c6de]  endthreadex+0x3a
C  [msvcr100.dll+0x5c788]  endthreadex+0xe4
C  [kernel32.dll+0x13677]  BaseThreadInitThunk+0x12
C  [ntdll.dll+0x39f02]  RtlInitializeExceptionChain+0x63
C  [ntdll.dll+0x39ed5]  RtlInitializeExceptionChain+0x36

VM_Operation (0x2cbee7ac): G1IncCollectionPause, mode: safepoint, requested by thread 0x2c9ad400

                                    

Comments
EVALUATION

See main CR
                                     
2011-10-22
EVALUATION

http://hg.openjdk.java.net/hsx/hsx22/hotspot/rev/9a9821a0bc8b
                                     
2011-10-12
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/273b46400613
                                     
2011-09-28
SUGGESTED FIX

1. Move the marking call which marks self-forwarded root objects in G1ParCopyClosure::do_oop_work out of the "is forwarded" if-branch to the enclosing if-branch.

2. Propagate the "should_mark_object" template parameter (which is true for root scanning closures during initial mark pauses) through copy_to_survivor_space to the evacuation handling code. The thread that successfully forewards the root object to itself is reponsible for marking the object.

I chose #2.
                                     
2011-09-02
EVALUATION

If there's only a single pointer to a root object, and we execute copy_to_survivor space and get an evacuation failure during an initial mark pause, then there's a chance we won't mark the root.

If there are multple pointers to the root object then following the second path to the object will cause it to be marked. Alternatively if there are multiple GC threads racing to forward the object then a thread that has some space could succeed and therefore no evacuation failure.
                                     
2011-09-02



Hardware and Software, Engineered to Work Together