On Thu, 8 Sep 2022 07:57:36 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
> I have been looking into `make clean-images images` performance, and realized > jmod keeps compressing files with default compression level. Tuning that > toward lighter compression levels improves build performance considerably, > without a heavy loss in *.jmod sizes. > > This PR allows JMOD to select the compression level. Follow-ups would use > this in the build system, see #10214. > > This change nominally requires CSR, but I would like to gauge the reaction to > this patch first, before submitting a formal CSR. The interesting asymmetry > against `jlink` is: `jlink` provides `--compress` option that only takes `2` > for "ZIP compression". I would argue it would be beneficial to add > `--compression-level` to `jlink` as well, so to select the compression level > there too. It's reasonable for jmod tool to support `--compress-level` option to specify the compression level. The JMOD file format is not specified but the implementation uses ZIP. Compression level from 0-9 makes sense for ZIP but may not be applicable if the JMOD file format is changed. But it may be okay to worry about that when the file format is changed. For jlink, when resources are compressed in writing to jimage, there would be performance overhead in reading and decompressing the resources at runtime. I'd be interested in knowing the tradeoff between the smaller jimage vs the runtime overhead in decompressing the resources. I'd advice to separate the jmod compression level change from jlink compression level discussion. ------------- PR: https://git.openjdk.org/jdk/pull/10213
