[Note: the resolution of this bug was to remove the --compress=2 option as it existed before 9-b158, and renumber the compression modes as per the below suggestion]

From the performance measurement (see JDK-8157991):

-compress=0 drops the size of lib/modules by ~30% (106M -> 69.5M), and actually seems to benefit startup in simple tests (~8 ms improvement on Hello World).
--compress=1 drops the size of lib/modules by ~54% (106M -> 49M), but comes with a penalty to startup (~8ms slowdown on Hello World)
--compress=2 drops the size of lib/modules by ~53% (106M -> 49.5M), but comes with an even greater penalty to startup (~13ms slowdown on Hello World)

A quick run of javac that adds about 250ms on a run that usually takes around 500m when the JDK is built with --compress=0

The other observations still appear valid though: the two different compression schemes shouldn't be used together (--compress=2), --compress=0 gives less of a slowdown - if any - on many applications, while --compress=1 is better at compressing but has larger runtime overhead.

This suggests that --compress=2 can be dropped. Also compression level = 0 could be interpreted as no compression. Suggest to start the compression level to 1. The higher the level the better compression but the startup performance overhead may be higher.

Suggest to rename level 0 to 1, level 1 to 2. Only support two levels.