On Tue, 13 Sep 2022 07:42:33 GMT, Aleksey Shipilev <[email protected]> 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.
>>
>> The interesting asymmetry against `jlink` is: `jlink` provides `--compress`
>> option that only takes `2` for "ZIP compression". (Separately, we could
>> argue if it would be beneficial to extend `--compress` to `jlink` as well,
>> so to select the compression level there too.)
>
> Aleksey Shipilev has updated the pull request incrementally with one
> additional commit since the last revision:
>
> More review comments
src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 66:
> 64: private final ZipOutputStream zos;
> 65: private final LocalDateTime date;
> 66: private JmodOutputStream(OutputStream out, LocalDateTime date, int
> compLevel) {
Nit - I think this should be `compressLevel` just like the param name to the
static method.
src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1196:
> 1194: }
> 1195: try {
> 1196: int level = Integer.parseInt(value.substring(idx + 1));
If I'm reading this code correctly, then this call to `substring` can
potentially end in a `IndexOutOfBoundsException` if the value is `zip-`.
Perhaps add a check above to verify that `idx != value.length()`?
-------------
PR: https://git.openjdk.org/jdk/pull/10213
