| Other |
|---|
| tbdUnresolved |
|
Duplicate :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
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.
|