United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6840775 Multiple JVM crashes seen with 1.6.0_10 through early access of 1.6.0_14 - possibly related to GC
JDK-6840775 : Multiple JVM crashes seen with 1.6.0_10 through early access of 1.6.0_14 - possibly related to GC

Details
Type:
Bug
Submit Date:
2009-05-13
Status:
Resolved
Updated Date:
2011-03-10
Project Name:
JDK
Resolved Date:
2010-05-25
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.0,6u7-rev,6u13,6u14
Fixed Versions:
6u18 (b01)

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

Sub Tasks

Description
Customer has a J2EE application which they are migrating from Java 1.5 to Java 1.6.

After migration, they're experiencing all kinds of crashes of the JVM, with essentially the same code as they had before.

While analyzing the problem, they created a few stand-alone java programs that can manifest some of the crashes without the entire platform code (in excess of 1.4 million lines of code), external libraries of application servers.  Please see the attached jar file for the test cases.

Details on the crashes their experiencing are posted at http://forums.sun.com/thread.jspa?threadID=5384686

Test cases shows various SIGBUS crashes.  The crashes mostly occur when using CMS, but problems can also be seen when using the default gc as chosen by ergonomics.  So it is possible we have a C2 issue here as well as an issue with GC.

Customer is running the application on a Solaris 10 (non zoned) Sun Sparc T5220.

Please see comments section of the bug for the steps to reproduce these crashes.

I noticed that the crashes from the test cases occur fairly quickly with 1.6.0_10 through early access of 1.6.0_14.  In my tests, I have not reproduced the crash with 1.6.0_05 and 1.6.0_07 yet.  Although the _05 test had to be terminated due to a system resource issue.  The _07 test has been currently running for about 18 hours now.  It is interesting to note that 1.6.0_05 and 1.6.0_07 are using hotspot 10 while 1.6.0_10 and higher are using hotspot 11.
.

                                    

Comments
EVALUATION

-XX:-ReduceFieldZeroing -XX:-ReduceInitialCardMarks -XX:-ReduceBulkZeroing
                                     
2009-05-29
WORK AROUND

-XX:-ReduceFieldZeroing -XX:-ReduceInitialCardMarks -XX:-ReduceBulkZeroing
                                     
2009-05-29
SUGGESTED FIX

Disable intrinsics: Arrays.copyOf(), Arrays.copyOfRegion(), Object.clone() in 1.6.0_10 through 1.6.0_14:

diff -r 6af0a709d52b src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp	Wed Mar 11 14:16:13 2009 -0700
+++ b/src/share/vm/runtime/globals.hpp	Mon Jun 08 17:17:06 2009 -0700
@@ -450,7 +450,7 @@ class CommandLineFlags {
           "inline Object::hashCode() native that is known to be part "      \
           "of base library DLL")                                            \
                                                                             \
-  develop(bool, InlineObjectCopy, true,                                     \
+  develop(bool, InlineObjectCopy, false,                                     \
           "inline Object.clone and Arrays.copyOf[Range] intrinsics")        \
                                                                             \
   develop(bool, InlineNatives, true,                                        \


It will be fixed in jdk 7.
                                     
2009-06-09
EVALUATION

Next instrinsics introduced in HS10/1.6.0_10 are broken:

 Arrays.copyOf(), Arrays.copyOfRegion(), Object.clone()

They will fail deoptimization and GC events because they have incomplete jvm state.
                                     
2009-06-09
EVALUATION

The deoptimization problem in Arrays.copyOf(), Arrays.copyOfRegion(), Object.clone() will be fixed in separate bug:

6833129: specjvm98 fails with NullPointerException in the compiler with -XX:DeoptimizeALot
                                     
2009-06-10
EVALUATION

The problem is for the slow_arraycopy call we create a separate value for allocation result
which lives only until the call:

      // Promote from rawptr to oop, so it looks right in the call's GC map.
      dest = _gvn.transform( new(C,2) CheckCastPPNode(control(), dest,
                                                      TypeInstPtr::NOTNULL) );
      // Edit the call's debug-info to avoid referring to original_dest.
      // (The problem with original_dest is that it isn't ready until
      // after the InitializeNode completes, but this stuff is before.)
      // Substitute in the locally valid dest_oop.
      replace_in_map(original_dest, dest);

    generate_slow_arraycopy(adr_type,
                            src, src_offset, dest, dest_offset,
                            copy_length, nargs);

And the original CheckCastPP is pined below the call so it lives only after the call:

    InitializeNode* init = insert_mem_bar_volatile(Op_Initialize,
                                                   Compile::AliasIdxRaw,
                                                   raw_dest)->as_Initialize();
    _gvn.hash_delete(original_dest);
    original_dest->set_req(0, control());
    _gvn.hash_find_insert(original_dest);  // put back into GVN table

So there is no live oop value (only raw) across the call which should be put into OopMap.

As result the newly allocated array in copyOf() intrinsic is not put into OopMap and we are screwed
when GC happens on the exit from the call to slow_arraycopy:

c55       MOV    [ESP + #96],EBX <<<<<<<<<<<<< newly allocated objarray
c59       #checkcastPP of EBX
c6f       MOV    ECX,EDX
c71       XOR    EDX,EDX
c73       MOV    [ESP + #0],EBX
c76       XOR    EBX,EBX
c78       MOV    [ESP + #4],EBX
c7c       MOV    [ESP + #8],ESI
c80       NOP     # 3 bytes pad for loops and calls
c83       CALL,static  wrapper for: slow_arraycopy
        # java.util.ArrayList::toArray @ bci:21  L[0]=_ L[1]=_
        # com.sigma.samp.vframe.entityutil.XmlObjectSerializerBase::assocListToXmlObject @ bci:162  L[0]=_ L[1]=_ L[2]=_ L[3]=esp + #16 L[4]=_ L[5]=_ L[6]=_ L[7]=_ L[8]=_ STK[0]=esp + #16
        # OopMap{[16]=Oop off=3208}  <<<<<<<<<<<<<<<< [esp + #96] not on oopMap
c88
c88   B170: #    B112 <- B169  Freq: 0.0162912
        # Block is sole successor of call
c88       MOV    EBX,[ESP + #96]         <<<<<<<<<<<<<<<< restored old value
c8c       JMP    B112
                                     
2009-06-10
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/acba6af809c8
                                     
2009-07-02
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/acba6af809c8
                                     
2009-07-11
EVALUATION

fixed in 6u18b01.
                                     
2010-04-02



Hardware and Software, Engineered to Work Together