RFR: 8299748: java/util/zip/Deinflate.java failing on s390x [v2]

[Jaikiran Pai]

On Mon, 6 Mar 2023 13:10:57 GMT, Ilya Leoshkevich <duke at openjdk.org> wrote:

>> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change acc to Alan comments
>
>> Finally, are you or someone in your team, in contact with the author(s) of the custom zlib implementation [iii-i/zlib at 1132034](https://github.com/iii-i/zlib/commit/113203437eda67261848b14b6c80a33ff7e33d34)? Would you be able to ask for their inputs on whether this (large?) difference in the deflated content size expected and are there any specific input (sizes) that this shows up or is it for all inputs?
> 
> This can happen for any poorly compressible inputs, regardless of their size. Here is the calculation for the worst case: https://github.com/iii-i/zlib/blob/dfltcc-20230109/contrib/s390/dfltcc.h#L17 (TL;DR: the size can double), but, of course, we don't expect this to be happening often.
> 
> Here are some benchmarking results: https://github.com/iii-i/zlib-ng/wiki/Performance-with-dfltcc-patch-applied-and-dfltcc-support-built-on-dfltcc-enabled-machine. The interesting data is in column `compressed_size` where `level` is 1. This is the hardware compressed size divided by the software compressed size. Most of the time it's +5-20%, in a few cases it compresses better than software, and only in one case (kennedy.xls) we see a big difference of +44%.
> 
> P.S. Here we are compressing random data, if I read the testcase correctly (`rnd.nextBytes(dataIn);`), so poor results are expected. Ideally we should emit stored blocks, but the hardware engine does not support this at the moment.

@iii-i Thank you Ilya for those details. I haven't fully caught up with them, but while you are here - In the benchmarking table, are the "compress_cpu" and the "compress_wall" too ratios of hardware compress time to software compress time for level 1 (BEST_SPEED)?

-------------

PR: https://git.openjdk.org/jdk/pull/12283