harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Optimizing jars
Date Sun, 03 Oct 2010 08:42:08 GMT
On 01/Oct/2010 16:43, Mark Hindess wrote:
> 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.

Do you have some measurements?  Why is it always going to be a disadvantage?

> 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.

What were you measuring? and what improvements did you see?

> 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.

You mean we can't influence how close separate JAR files are on a disk,
but we can influence the layout of an individual JAR file file?

I'd like to see some numbers on where the time is actually being spent
during start-up.

Is it really in searching and seeking?  It's not at all clear to me that
we can navigate the directory structure in the ZIP file format any
faster than an OS can navigate the file system directories.

(You will remember this discussion from 2008 and associated work, e.g.


View raw message