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

CRC32C fails on x86 hardware without CLMUL support

    Details

      Description

      This seems to be a day-one bug which was introduced by JDK-8134553 "CRC32C implementations for x86/x64 targets". It wasn't detected until know because there are not many machines which don't support CLMUL and the CRC32 jtreg tests didn't really work.

      During our work on JDK-8176580 "[ppc, s390] CRC32C: wrong checksum result in some cases" we fixed the two regression tests test/compiler/intrinsics/zip/TestCRC32.java and test/compiler/intrinsics/zip/TestCRC32C.java which finally unveiled the problem on old x86 hardware.

      We will now push JDK-8176580 without the fixed regression tests. The new version of the tests are available from the following webrev:

      http://cr.openjdk.java.net/~lucy/webrevs/8176580.03/

      and they should be pushed together with the fix for this issue.

      Running these test on old hardware will produce the following error:

      command: main -Xbatch compiler.intrinsics.zip.TestCRC32C -m
      reason: User specified action: run main/othervm/timeout=600 -Xbatch compiler.intrinsics.zip.TestCRC32C -m
      Mode: othervm [/othervm specified]
      elapsed time (seconds): 1.915
      configuration:
      STDOUT:
      testing 1050 cases ...
      STDERR:
      ERROR: crc = 6f894393, crcReference = 2cdf6e8f
      java.lang.Exception: TestCRC32C Error
              at compiler.intrinsics.zip.TestCRC32C.check(TestCRC32C.java:218)
              at compiler.intrinsics.zip.TestCRC32C.test_multi(TestCRC32C.java:280)
              at compiler.intrinsics.zip.TestCRC32C.main(TestCRC32C.java:74)
              at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.base/java.lang.reflect.Method.invoke(Method.java:563)
              at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
              at java.base/java.lang.Thread.run(Thread.java:844)

      JavaTest Message: Test threw exception: java.lang.Exception: TestCRC32C Error
      JavaTest Message: shutting down test

      If you don't have old hardware available, you can still manually force the error as describe by Lutz in the mail tread at http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/026029.html and copied here for your convenience:

      The CRC32C implementation generates code depending on the CLMUL cpu feature being available. On most machines @Oracle and @SAP, this feature seems to be available – except for one of your MacOS test machines.

      To gain control over that feature, I have modified just one line in src/cpu/x86/vm/vm_version_x86_64.hpp like this:
           static bool supports_clmul() { return ((_features & CPU_CLMUL) != 0) && UseNewCode; }

      The boolean UseNewCode is a command line parameter we use @SAP to make experimental code switchable during development. With that modification, I can force off the CLMUL feature at will. And voila, here is what I get (linux-x86_64):

         lu0084 PrivSrc/TestCRC> /<some path>/sapjvm_9/bin/java -XX:+UseNewCode TestCRC32C_OpenJDK -m
         updateBytesCRC32C: pclmulqdq = true.
         testing 1050 cases ...
         lu0084 PrivSrc/TestCRC> /<some path>/sapjvm_9/bin/java -XX:-UseNewCode TestCRC32C_OpenJDK -m
         updateBytesCRC32C: pclmulqdq = false.
         testing 1050 cases ...
         ERROR: crc = 6f894393, crcReference = 2cdf6e8f
         iteration 0: offsets[0] = 0 sizes[30] = 1024
         Exception: java.lang.Exception: TestCRC32C Error
         Exception in thread "main" java.lang.Exception: java.lang.Exception: TestCRC32C Error
                 at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:306)
                 at TestCRC32C_OpenJDK.main(TestCRC32C_OpenJDK.java:74)
         Caused by: java.lang.Exception: TestCRC32C Error
                 at TestCRC32C_OpenJDK.test_multi(TestCRC32C_OpenJDK.java:298)
                 ... 1 more
         lu0084 PrivSrc/TestCRC>

      Output on MacOS is the same. I did not try solaris-x86_64.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                srukmannagar Shravya Rukmannagari
                Reporter:
                simonis Volker Simonis
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: