United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6565178 unhandled explicit exception in compiled code
JDK-6565178 : unhandled explicit exception in compiled code

Details
Type:
Bug
Submit Date:
2007-06-04
Status:
Resolved
Updated Date:
2011-01-20
Project Name:
JDK
Resolved Date:
2007-06-20
Component:
hotspot
OS:
solaris_9,linux_sun,windows_xp
Sub-Component:
compiler
CPU:
x86,sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0,5.0u7,6
Fixed Versions:
hs10 (b14)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:

Sub Tasks

Description
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

                                    

Comments
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.
                                     
2007-06-04
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.
                                     
2007-06-06
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/
                                     
2007-06-06



Hardware and Software, Engineered to Work Together