Evaluation

I report my compression results in Table 6. I used the move-to-front with transients and context scheme for references and used calculated stack state to collapse JVM opcodes.

I report the size of jar files, j0r.gz files (jar files without individual classfile compression but with overall zlib compression), Jazz files [BHV98] (Section 13.1) and the archives produced by the techniques described in this paper.

I also report, in the archives I produce, how much space is occupied by strings (string constants, class and method names, ...), opcodes, integers, references and other (including floating point constants, branch offsets and registers). As you can see, no one element dominates, so obtaining substantial additional reduction in archive size would likely require substantial reductions in all elements.

 

Table 7: Execution times

	Compression	Decompression
File	time (secs)	time (secs)	Kbytes/sec
rt	170.62	8.58	125
swingall	54.97	2.92	116
tools	27.61	1.51	135
icebrowserbean	4.72	0.31	127
jmark20	5.59	0.42	83
visaj	36.5	2.07	115
ImageEditor	7.47	0.53	122
Hanoi	1.74	0.13	101
Hanoi_big	1.07	0.10	86
Hanoi_jax	0.80	0.09	75
javafig	8.72	0.41	157
javafig_dashO	7.16	0.49	109
201_compress	0.25	0.09	31
202_jess	3.18	0.24	95
205_raytrace	1.02	0.13	56
209_db	0.27	0.09	31
213_javac	6.56	0.39	129
222_mpegaudio	2.42	0.19	121
228_jack	2.50	0.18	92

Execution time

We timed the execution speed of both the compression routine and the decompression routine. In the decompressor, we just computed the time required to build each classfile internally; we did not include the time required to store the class files into a jar file. Thus, these times would be appropriate for an application using eager class loading (Section 11).

The decompressor can decompress about 75-120 Kbytes of wire-format classfiles per second (which would expand into a substantially larger collection of classfiles). This is on a Sun Ultra 5 workstation with a 333Mhz processor using the Sun Solaris production JVM, version 1.2fcs, which achieves a JVM98 Specmark of 16.6.

The compressor is about 15 times slower than the decompressor, but at the moment it still contains a fair bit of code for generating statistics and is a very general purpose compressor (i.e., can implement many different compression schemes). A rewrite of the compressor should provide substantial speed improvements.

The decompressor is 36 Kbytes in jar format, so if the decompressor had to be downloaded along with a packed archived, it would only be advantageous for larger archives. The decompressor is 23 Kbytes in j0r.gz format, so it could be loaded by first downloading (a tiny) a classloader than understood j0r.gz archives, and then downloading the decompressor. If the decompressor were installed as an standard extension, then this wouldn't be an issue and would be fine for even very small archives.