JDK-6755988 : G1: assert(new_obj != 0 || ... "should be forwarded")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14,hs17
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,x86
  • Submitted: 2008-10-04
  • Updated: 2013-09-18
  • Resolved: 2011-04-23
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
6u21Fixed 7Fixed hs17Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Jim reported a couple of more:

Two of these assertions in Sept:

/java/sqe/results/vm/gtee/JDK7/NIGHTLY/VM/2008-09-01/G1_GC_Baseline/vm/solaris-sparcv9/server/mixed/vm-solaris-sparcv9_server_mixed_nsk.stress.testlist2008-09-01-23-56-06/ResultDir/except007/except007.log:[2008-09-02T12:43:43.34] #  Error: assert(new_obj != 0L || obj->mark() == markOopDesc::prototype() || (UseBiasedLocking && obj->mark()->has_bias_pattern()) || obj->is_shared(),"should be forwarded")

The above test is:

    nsk/stress/except/except007


/java/sqe/results/vm/gtee/JDK7/NIGHTLY/VM/2008-09-18/G1_GC_Baseline/vm/windows-i586/client/mixed/vm-windows-i586_client_mixed_nsk.stress.testlist2008-09-19-00-04-54/ResultDir/except001/except001.log:[2008-09-19T08:47:43.72] #  Error: assert(new_obj != 0 || obj->mark() == markOopDesc::prototype() || (UseBiasedLocking && obj->mark()->has_bias_pattern()) || obj->is_shared(),"should be forwarded")

The above test is:

    nsk/stress/except/except001
Here is an entry from my nightly analysis report:

New JDI_REGRESSION failures (from 2008.10.02)
*   com/sun/jdi/FinalizerTest.java
        This test failed the following assert:

            Internal Error (src/share/vm/gc_implementation/shared/
                markSweep.inline.hpp:90)
            Error: assert(new_obj != 0
                || obj->mark() == markOopDesc::prototype()
                || (UseBiasedLocking && obj->mark()->has_bias_pattern())
                || obj->is_shared(),"should be forwarded")

        on Solaris X86 Server VM (machine vm-b1600x-8). This test is
        covered by the following bug:

            6609520 4/3 com/sun/jdk/FinalizerTest.java failed

        However, 6609520 does not cover this failure mode.

Here is the URL:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-10-02/Serv_Baseline/javase/solaris-i586/server/mixed/solaris-i586_server_mixed_JDI_REGRESSION/analysis.html

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/master/rev/34571037987c,ChangeRequest=6755988
26-03-2010

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/664ae0c5e0e5,ChangeRequest=6755988
18-03-2010

SUGGESTED FIX The fix is to NOT follow the humongous object allocation path if the space being allocated is for a TLAB. This involves passing a boolean parameter to the various G1 allocation routines.
04-03-2010

EVALUATION We allocate a TLAB that is larger than the humongous threshold causing the region to be tagged as starting a humongous object. A series of smaller objects is then allocated from the TLAB. The objects in the TLAB are correctly marked because the marking code follows object references. The G1 MarkSweep code that copies objects to their new locations assumes that a humongous region set is dedicated to a single humongous object starting at base of the "startsHumongous" region. This forwards the object at the base of the TLAB to itself whil ignoring subsequent objects in the TLAB. When we come to fix up the pointers we detect that the subsequent objects in the TLAB have not been forwarded and so it looks like a bad oop.
04-03-2010