Bug ID: JDK-6565178 unhandled explicit exception in compiled code

Versions (Unresolved/Resolved/Fixed)

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
6u4Fixed	7Fixed	hs10Fixed

The symptom is the old "unhandled 
explicit exception in compiled code" guarantee.  This is JDK7 b12 on 
Solaris 10 x86 (Intel) running SPECjbb2005.  I am running with a 
modified TreeMap however the code changes are pure Java and should not 
cause a crash.  However the crash comes while executing the modified 
TreeMap code, specifically line 1139:

      Entry<K,V> cur = root;
      if (first != null && cur != null) {
        int cmp = compare(first.key, cur.key);
        while (cur != null && cmp != 0) {
          stack.push(cur);
          // if (cur == null) throw new NullPointerException();
          if (cmp < 0) cur = cur.left;   // line 1139: CRASHES HERE
          else cur = cur.right;
        }
      }

(Complete TreeMap.java listing is attached.)  Note that this code 
actually has a bug in it: the variable "cmp" is not updated each time 
through the loop.  Still, it shouldn't crash.  :) 

So I ran this with fastdebug + PrintNMethods; yielding the message 
"implicit exception happened at 0xfa16f217":

  0xfa16f1e5: movl   0x14(%esi),%ebp
  0xfa16f1e8: movl   %ebp,0x18(%esp,1)
  0xfa16f1ec: leal   0x14(%ebx),%ebp
  0xfa16f1ef: movl   %ebp,0x1c(%esp,1)
  0xfa16f1f3: leal   0xc(%ebx),%ebp
  0xfa16f1f6: movl   %ebp,0x20(%esp,1)
  0xfa16f1fa: movl   0x18(%esp,1),%ebp
  0xfa16f1fe: movl   0x14(%ebp),%ebp
  0xfa16f201: movl   %ebp,0x28(%esp,1)
  0xfa16f205: leal   0x10(%ebx),%ebp
  0xfa16f208: movl   %ebp,0x2c(%esp,1)
  0xfa16f20c: movl   0x28(%esp,1),%ebp
  0xfa16f210: movl   0x14(%ebp),%ebp
  0xfa16f213: movl   %ebp,0x30(%esp,1)
  0xfa16f217: movl   0x14(%ebp),%esi    ;*getfield left   <--- CRASH HERE
                                        ; - 
java.util.TreeMap$PrivateEntryIterator::<init>@104 (line 1139)

Again, the complete PrintNMethods listing for 
TreeMap$PrivateEntryIterator::<init> is attached.

Any clues or debugging hints are appreciated.  If it's unrecognized I'll 
just extract a testcase and file a bug.

From Steve Bohne

Run specjbb2005 with modified java/util/TreeMap.java (attached)

java -test -XX:CICompilerCount=1 -Xbatch -Xbootclasspath/p:./java/util/TreeMap.class -classpath ./jbb.jar:./check.jar -XX:+PrintCompilation -Xmx1g spec.jbb.JBBmain -propfile SPECjbb.props

EVALUATION In the modified PrivateEntryIterator of TreeMap, after partial peeling the load of cur.left has a control edge from outside the loop, rather than the loop head. Then after loop unrolling the load from the second iteration floats up above the "if (cur == null) break" from the first iteration, causing the SEGV. Fix is to redirect control to the new loop head if a cloned node in the not_peeled region has control that points into the peeled region. This necessary because the cloned&peeled region will be outside the loop. Leaving the control to point outside the loop can cause incorrect scheduling after unrolling.

06-06-2007

SUGGESTED FIX PRT data: /net/prt-web.sfbay/prt-workspaces/20070606063754.nips.bug6565178 Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070606063754.nips.bug6565178/

06-06-2007

EVALUATION After loop unswitching and partial peeling (the latter is likely at fault), the load of cur.left has a control edge from outside the loop, rather the loop head. Then after loop unrolling (one unroll enough) the load from the second iteration floats up above the "if (cur == null) break" from the first iteration, causing the SEGV.

04-06-2007

Duplicate :	JDK-6617341 - JVM crash at symbolOopDesc::as_klass_external_name
Duplicate :	JDK-6532244 - 5.0 U7 crash: Unhandled implicit exception in compiled code