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: 6321689
Votes 0
Synopsis Ideal_DU_postCCP not conservative enough
Category hotspot:compiler2
Reported Against b03
Release Fixed mustang(b56), 5.0u14(b01) (Bug ID:2149549) , 1.4.2_18-rev(b11) (Bug ID:2166320) , 1.4.2_19(b02) (Bug ID:2168779)
State 10-Fix Delivered, bug
Priority: 3-Medium
Related Bugs 6527749 , 6715676
Submit Date 08-SEP-2005
Description
Cliff Click of  customer  reports:

Hi!  Long time no bug report - so I thought you might need one.  :-)
This one happens with "java_g -server -Xmx512m -Xms512m -Xbatch 
-XX:+PrintCompilation -XX:CompileOnly=foo.insert foo" and the included 
foo.java, on 1.4.2_03 SparcV9 for sure (and +PrintOptoAssembly shows a 
load scheduled before the null-check).  I get funny OOM errors with the 
product versions of later X86 & Sparc things; not sure if it's the same 
crash.


Cliff

------------------------------------------------------------------------
 From my putback msg:

The Ideal_DU_postCCP function removes CastPP's and replaces them with 
control edges on memory ops.  In order to give some scheduling freedom, 
it tries to find a least restrictive control input that is also 
sufficient to prevent hoisting above any needed null-check.  In the case 
of CountedLoops, it is willing to use a pre-loop control input.  This is 
not always correct: if the base value is known not-null but is a merge 
at the loop head - at is null-checked on entry AND at the loop bottom - 
then the old code would allow the control edge to move up to the 
null-check on entry.  The memory op could not float up out of the loop 
because the base value merges at the loop head.

If we later unrolled the loop, the cloned memory op would then take 
control from before the loop (like the original now does) and its base 
input from the unrolled prior loop body - which has no merging phi and 
whose CastPP was removed before unrolling.  Hence the cloned memory op 
could float above a needed null test. 

Fix is to not lift the control above a CountedLoop, unless the base 
value does not merge at the loop head (and is available already 
null-checked before loop).

Test case:

class foo  {
  public static void main(String argv[]) {
    System.out.println("Warmup");
    foo F = new foo();
    char [] C = new char[100];
    for( int i=0; i<100000; i++ ) {
      String s = Integer.toString(i);
      s.getChars(0,s.length(),C,0);
      F.insert(C);
    }
    System.out.println("Done ");
  }

  private final Node ROOT = new Node();
  private static class Node {
    final Node _next[] = new Node[128];
  }

  public Node insert(char [] C) {
    int len = C.length;
    Node node = ROOT;
    int j = 0;

    for(; j < len; j++) {
      Node node1 = node._next[C[j]];
      if( node1 == null ) break;
      node = node1;  
    }

    for(; j < len; j++) {
      Node node2 = new Node();
      node._next[C[j]] = node2;
      node = node2;
    }

    return node;
  }
}
Posted Date : 2005-09-08 22:29:34.0
Work Around
N/A
Evaluation
Customer's evaluation is correct.
Posted Date : 2005-09-08 22:30:54.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang