United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6700047 C2 failed in idom_no_update
6700047 : C2 failed in idom_no_update

Details
Type:
Bug
Submit Date:
2008-05-09
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u4
Fixed Versions:
hs14

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

Sub Tasks

Description
Customer encuntered a crash when C2 is in compilation. Stack trace:

(dbx) where
current thread: t@20
  [1] __lwp_kill(0x14, 0x6), at 0xfef10d77
  [2] raise(0x6), at 0xfeebd093
  [3] abort(0xfecb8000, 0xf23da5a8, 0xf23da5a8, 0xfeb7d838, 0x1, 0x82d5000), at 0xfeea0b29
  [4] os::abort(0x1), at 0xfead7440
  [5] VMError::report_and_die(0xf23da740), at 0xfeb7d838
  [6] JVM_handle_solaris_signal(0xb, 0xf23daa5c, 0xf23da85c, 0x1), at 0xfe71bf0b
  [7] signalHandler(0xb, 0xf23daa5c, 0xf23da85c), at 0xfe71b7c2
  [8] __sighndlr(0xb, 0xf23daa5c, 0xf23da85c, 0xfe71b79c), at 0xfef1013f
  [9] call_user_handler(0xb, 0xf23daa5c, 0xf23da85c), at 0xfef066ed
  [10] sigacthandler(0xb, 0xf23daa5c, 0xf23da85c, 0xf, 0x0, 0x4), at 0xfef0686d
  ---- called from signal handler with signal 11 (SIGSEGV) ------
=>[11] PhaseIdealLoop::idom_no_update(0xf23db494, 0x83c4fd0), at 0xfe6c9d45
  [12] PhaseIdealLoop::clone_loop(0xf23db494, 0x83e2888, 0xf23dacc0, 0x16, 0x0), at 0xfeaa47c4
  [13] PhaseIdealLoop::do_unroll(0xf23db494, 0x83e2888, 0xf23dacc0, 0x1), at 0xfea9ee58
  [14] IdealLoopTree::iteration_split_impl(0x83e2888, 0xf23db494, 0xf23dacc0), at 0xfe70c992
  [15] IdealLoopTree::iteration_split(0x83e28c8, 0xf23db494, 0xf23dacc0), at 0xfe73b12d
  [16] PhaseIdealLoop::PhaseIdealLoop(0xf23db494, 0xf23dae70, 0x0, 0x0), at 0xfeaa28b6
  [17] Compile::Optimize(0xf23dc4e0), at 0xfe7592a4
  [18] Compile::Compile(0xf23dc4e0, 0xf23dc9d0, 0x806d788, 0x84a3aa0, 0xffffffff, 0x1), at 0xfe90cf66
  [19] C2Compiler::compile_method(0x806d788, 0xf23dc9d0, 0x84a3aa0, 0xffffffff), at 0xfe755fd6
  [20] CompileBroker::invoke_compiler_on_method(0x82f0038), at 0xfe7564d7
  [21] CompileBroker::compiler_thread_loop(0xfecb8000, 0x98, 0xf23dcbc8, 0xfe7811d8, 0x82d5000, 0x82d5000), at 0xfe7b799c
  [22] compiler_thread_entry(0x82d5000, 0x82d5000), at 0xfe7b9760
  [23] JavaThread::thread_main_inner(0x82d5000), at 0xfe7811d8
  [24] JavaThread::run(0x82d5000), at 0xfe781182
  [25] java_start(0x82d5000), at 0xfead6d62
  [26] _thr_setup(0xfe244400), at 0xfef0fd52
  [27] _lwp_start(), at 0xfef10040
This is the minimal test case from the other bug.

public class crash {
    public static void main(String[] args) {
        for (int i = 0; i < 100000; i++) {
            intToLeftPaddedAsciiBytes();
        }
    }

    public static int intToLeftPaddedAsciiBytes() {
        int offset = 40;
        int q;
        int r;
        int         i   = 100;
        int result = 1;
        while (offset > 0) {
            q = (i * 52429) >>> (16+3);
            r = i - (q * 10);
            offset--;
            i = q;
            if (i == 0) {
                break;
            }
        }
        if (offset > 0) {
            for(int j = 0; j < offset; j++) {
                result++;
            }
        }
        return result;
    }


}

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/020a0b730379
                                     
2008-07-26
WORK AROUND

-XX:-PartialPeelLoop will turn off the problematic code.
                                     
2008-05-21
EVALUATION

This appears to be a bug in partial peeling of non counted loops.  The limit of a counted loop is computed in a preceeding non-counted loop.  When that non counted loop gets peeled the limit of the counted loop is part of the peeled region and gets cloned.  The clone is place at the use which is inside the counted loop.  The means the limit of the counted loop will be cloned when the pre/main/post transformation is done which causes it to screw up.  Placing the clone outside the loop seems to fix the problem.
                                     
2008-05-21
EVALUATION

We seem to be crashing in this code in clone loop.

        while( !loop->is_member( get_loop( cfg ) ) ) {
          prev = cfg;
          cfg = cfg->_idx >= new_counter ? cfg->in(2) : idom(cfg);
        }

We've walked the idom up to root and die there.  I haven't found the problematic node yet.
                                     
2008-05-15



Hardware and Software, Engineered to Work Together