Runtime impact of compressing class files in the module library

[Peter Jensen]

Just joining the alias.

I wrote a test program that measures the time to
1/ read all API classes in a jar file, in jar entry order
2/ load all the same classes by name, in order of Hashset iteration (set 
populated during read test).

Gary Adam's helped run this on a BeagleBoard, at different CPU speed, 
using an Embedded SE build,
with a compressed vs. uncompressed rt.jar. Note: Embedded SE compress by 
default. I'm not sure
if it's 'zip -9' or standard zip compression.

Both test show linear dependency between time and cpu speed. That is, 
the workload
consist of a component inversely proportional to CPU frequency, and a 
constant component
(e.g. IO wait time).

The CPU sensitive component shows a worst-case class-loading overhead of 
7 to 6 (17%)
(worst-case is for an infinitely fast storage. With high CPU to IO 
performance you get better results).

This for an approx. 50% reduction in jar file size.

Results and regression analysis attached.

-------- Original Message --------
Subject: 	Fwd: Compressing class files in the module library
Date: 	Wed, 09 Nov 2011 13:27:23 -0500
From: 	Gary Adams <gary.adams at oracle.com>

	



fyi

-------- Original Message --------
Subject: 	Compressing class files in the module library
Date: 	Wed, 09 Nov 2011 18:21:07 +0000
From: 	Alan Bateman <Alan.Bateman at oracle.com>
To: 	jigsaw-dev <jigsaw-dev at openjdk.java.net>



I have an initial patch [1] to compress the classes of modules in the
module library. It essentially adds an option to "jmod create" so that
the classes of any modules installed into the library get compressed.
The patch also adds a build option to enable compression in the system
libraries of the images that the build generates.

Before finishing this I'd like to get some input on a few points. The
first is whether it's reasonable to enable compression when creating the
module library? The alternative is install time so that it's on a per
module basis. The former is less flexible but as the module library
format evolves it may not be feasible to have a mix of compressed and
uncompressed modules.

The other question is suggestions for the option name. For now it's -9
or --enable-compression (-9 influenced by the zip -9 option for
compress better). I'm looking for better suggestions.

Thanks,

-Alan.

[1]http://cr.openjdk.java.net/~alanb/ModuleLibraryCompression/webrev/