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

[Ilya Leoshkevich]

On Thu, 2 Feb 2023 08:27:55 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> DeInflate.java test fails on s390x platform because size for out1 array which is responsible for storing the compressed data is insufficient. And being unable to write whole compressed data on array, on s390 whole data can't be recovered after compression. So this fix increase Array size (for s390).
>
> 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%.

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

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