Our modular structure means we have many jars that need to be read at startup, this is always going to give us a disadvantage in terms of startup time compared to implementations with fewer jars.
I was reading: http://blog.mozilla.com/tglek/2010/09/14/firefox-4-jar-jar-jar/ and wondered if perhaps some of these techniques could be employed to help us reduce the disadvantage a little. So I took a federated build and tried: target/hdk/jdk/jre/bin/java -verbose:class -cp ~/hy/java HelloWorld \ >trace.log 2>&1 # create one log file per jar in trace subdir, one class filename per line class-load-by-jar trace.log cp -pr target target.new python optimizejars.py --optimize trace \ target{,.new}/hdk/jdk/jre/lib/boot python optimizejars.py --optimize trace \ target{,.new}/hdk/jdk/jre/bin/default so now new contains optimised versions of the jars need to run HelloWorld. I then obtained some timing data. The figures I get back weren't really conclusive - on one machine it showed improvement but not on another. I tried the same experiment with a j9 vm but the zip implementation is obviously more fragile as it crashed complaining about not finding java.lang.Object. Ironically given what I started thinking about, I suspect that the one big jar case (e.g. the RI) will probably see more benefit than the multiple jar case.[1] Anyway, I was just experimenting but I thought I'd write down what I found in case anyone had similar/better ideas. Regards, Mark. [1] Since you can't really reduce the disk seeks between multiple jars but you can within a single big jar. class-load-by-jar is: #!/usr/bin/perl use strict; use warnings; my %fh; mkdir 'trace', 0755; while (<>) { my ($class, $jar) = m!(?:Loaded|class load:) (\S+) from:? .*\/([^\/\.]+\.jar)! or next; my $fh = file_handle($2); print $fh $class, ".class\n"; } close $_ foreach (keys %fh); sub file_handle { my $jar = shift; return $fh{$jar} if (exists $fh{$jar}); open $fh{$jar}, '>', 'trace/'.$jar.'.log' or die "Failed to open $jar.log: $!\n"; $fh{$jar}; }
