RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases
Schmidt, Lutz
lutz.schmidt at sap.com
Wed Mar 15 16:55:04 UTC 2017
Hi Andrew, Volker,
What do you think about these test enhancements?
Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8176580.01/
Please note: the cpp files in the webrev remained unchanged.
I added some improvements (as I believe) to the TestCRC32(C).java files.
In some more detail:
The test now calculates a “reference CRC value”, based on a java implementation of the CRC32 algorithm. This reference value is used to verify all other crc values, in particular during initialization and warmup. Three additional test runs check a non-zero offset with –Xint, -Xcomp -XX:-TieredCompilation (C2 only), -Xcomp -XX:+TieredCompilation (C1 + C2).
Best regards,
Lutz
On 15.03.17, 11:50, "Volker Simonis" <volker.simonis at gmail.com> wrote:
On Tue, Mar 14, 2017 at 7:05 PM, Andrew Haley <aph at redhat.com> wrote:
> On 14/03/17 13:12, Schmidt, Lutz wrote:
>
>> Yes, one might think of running a test suite subset multiple times
>> with different parameters. In this case, -Xint and/or –Xcomp were
>> helpful. Forcing tests to run fully interpreted or fully compiled
>> helps in cases where a certain function, e.g. an intrinsic, is
>> invoked via distinct code paths.
>
> Right, so your patch should include that change to the test suite.
>
Hi Lutz,
I agree with Andrew. We should really fix the tests such that they
check the correctness of the intrinsics.
This may be tricky if all three, the interpreter, the client and the
server compiler use the same intrinsic implementation. You could
either copy the pure Java implementation into the test so that you can
compare the results of the intrinsic operation against it or you can
switch them off in the compilers with
"-XX:DisableIntrinsic=_updateBytesCRC32C
-XX:DisableIntrinsics=_updateDirectByteBufferCRC32C" and compare the
results. Not sure which solution is more practical, but I would be
really scared if we wouldn't have these test.
Regards,
Volker
> Andrew.
>
More information about the hotspot-compiler-dev
mailing list