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, 

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: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.
    > Andrew.

More information about the hotspot-compiler-dev mailing list