Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6700047
Votes 0
Synopsis C2 failed in idom_no_update
Category hotspot:compiler2
Reported Against b04 , b12
Release Fixed hs14(b03), 6u13-rev(b05) (Bug ID:2166521) , 6u14(b01) (Bug ID:2172749)
State 10-Fix Delivered, bug
Priority: 2-High
Related Bugs 6703556 , 6743188 , 5091921
Submit Date 09-MAY-2008
Description
Customer encuntered a crash when C2 is in compilation. Stack trace:

(dbx) where
current thread:   xxxxx@xxxxx  
  [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
Posted Date : 2008-05-09 22:08:18.0

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;
    }


}
Posted Date : 2008-05-21 19:26:06.0
Work Around
-XX:-PartialPeelLoop will turn off the problematic code.
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.
Posted Date : 2008-05-15 23:27:26.0

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.
Posted Date : 2008-05-21 19:26:06.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/020a0b730379
Posted Date : 2008-07-26 00:59:40.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang