Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6321689

Ideal_DU_postCCP not conservative enough

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 1.4.2_15, 5.0u8, 6
    • Fix Version/s: 6
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b56
    • CPU:
      x86, sparc
    • OS:
      generic, solaris_9, windows_2000

      Backports

        Description

        Cliff Click of Azul Systems 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;
          }
        }

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  rasbold Chuck Rasbold
                  Reporter:
                  rasbold Chuck Rasbold
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: