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

C2 performs unsigned comparison against -1


    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Environment:

      Fedora 19

    • Subcomponent:
    • Introduced In Build:
    • Resolved In Build:
    • CPU:
    • OS:



        C2 is incorrectly doing unsigned comparisons against -1.

        Attached is a sample Java source file and the corresponding class file (I have attached the class file as well in case the bug is dependant on the version javac used to compile the Java source).

        Also attached is a CompileCommandFile 'compile_files'

        If I then run this as following with a release build of the jdk9 tip as follows

        /work/images/jdk-release/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files TestMultiplyToLen

        I get the following

        Exception in thread "main" java.lang.IndexOutOfBoundsException
        at java.math.BigInteger.<init>(BigInteger.java:385)
        at java.math.BigInteger.<init>(BigInteger.java:422)
        at java.math.BigInteger.<init>(BigInteger.java:679)
        at TestMultiplyToLen.main(TestMultiplyToLen.java:91)

        The test should just print 'Success'

        If I take a look at the assembly output as follows

        /work/images/jdk-release/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly TestMultiplyToLen

        I see the following in the asm output (I have attached the assembler output in the file asm.out).

          0x00007f20b907aed6: cmp $0xffffffff,%r10d
          0x00007f20b907aeda: jbe 0x00007f20b907af46 ;*if_icmpge
                                                        ; - java.math.BigInteger::<init>@41 (line 381)
                                                        ; - java.math.BigInteger::<init>@6 (line 422)
                                                        ; - java.math.BigInteger::<init>@7 (line 679)

        So, here it is doing an unsigned comparison again -1 (0xffffffff). This results in the exception always being thrown.

        If I then build a slowdebug version and run it as follows

        /work/images/jdk-slowdebug/bin/java -Xcomp -XX:-TieredCompilation -XX:CompileCommandFile=compile_files -XX:+PrintCompilation -XX:+PrintIdeal -XX:+PrintOptoAssembly -XX:+PrintAssembly TestMultiplyToLen

        I see the following in the ideal graph (attached as file slowdebug.out)

         309 CmpU === _ 306 305 [[ 310 ]]
         305 ConI === 0 [[ 306 309 ]] #int:-1
         306 AddI === _ 66 305 [[ 309 ]] !orig=[304]
         66 LoadRange === 55 7 65 [[ 162 306 85 ]] @bottom[int:>=0]+12 * [narrow], idx=4; #int:>=0 !jvms: BigInteger::<init> @ bci:5 BigInteger::<init> @ bci:7

        So, here we can see that it is doing an unsigned comparison (node 309) against -1 (node 305)

        This is also reflected in the opto assembly (again in the attached file slowdebug.out)

        056 cmpl R10, #-1 # unsigned
        05a jbe,u B13 P=0.000001 C=-1.000000

        This bug also occurs in the aarch64 port. In fact I found it first in the aarch64 port except on the aarch64 port it is not necessary to do the -Xcomp -XX:CompileCommandFIle=... to force the bug, it just happens if you simply do -XX:-TieredCompilation

        The bug seems to have been introduced in the following changeset

        # HG changeset patch
        # User roland
        # Date 1426583191 -3600
        # Tue Mar 17 10:06:31 2015 +0100
        # Node ID f5fae6f265e2c403cc51046050a4702a33625038
        # Parent dbd15e131b5fc6e319e71c77c14d45eae623ed92
        8073480: C2 should optimize explicit range checks
        Summary: explicit range checks should be recognized by C2
        Reviewed-by: kvn, vlivanov

        If I back out this single changeset the bug goes away.


          1. asm.out
            75 kB
          2. compile_files
            2 kB
          3. slowdebug.out
            260 kB
          4. TestMultiplyToLen.class
            3 kB
          5. TestMultiplyToLen.java
            5 kB

            Issue Links



                • Assignee:
                  roland Roland Westrelin
                  enevill Ed Nevill
                • Votes:
                  0 Vote for this issue
                  3 Start watching this issue


                  • Due:

                    Time Tracking

                    Original Estimate - 2 days
                    Remaining Estimate - 2 days
                    Time Spent - Not Specified
                    Not Specified