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

[Amit Kumar]

On Tue, 7 Mar 2023 05:57:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> 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.
>
>> 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.
> 
> Thank you Ilya, that was helpful in understanding the current behaviour of this custom zlib implementation.

Hi @jaikiran @AlanBateman 

please review it..

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

PR Comment: https://git.openjdk.org/jdk/pull/12283#issuecomment-1522702761