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: [vm] Implement on-demand class library parsing to avoid unnecessary jar/zip parsing during startup (HARMONY-6039)
Date Wed, 10 Dec 2008 14:07:14 GMT
Xiao-Feng Li wrote:
> On Wed, Dec 10, 2008 at 9:11 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> So my question is where is the time being saved using this technique?
>> Is it the number of files we touch? e.g. disc seek time, or is it
>> searching through the ZIP directories looking for class files e.g. poor
>> ZIP performance for our usage, or ...
>> Given that the cold start times improve by 85% (20s down to 3s), and
>> warm start improves by ~18% (170ms down to 140ms), it is most likely the
>> 'getting the bits off disc' part.  Does that sound right?  Can we
>> measure it?
> I am also wondering about it. There are two ways to save time: one is
> to reduce the number of JARs by repackaging all the classes; the other
> is to reduce the number of JARs loaded. As I know, the first approach
> helps little. That probably means the disk seeking time is the major
> contributor of startup time.
> If this hypothesis is correct, then to delay the loading of JARs can
> benefit even if all the JARs are needed in the end by an application.
> The reason is the IO time can be overlapped with the computation time.

Yes, especially if we have the metadata that tells us where the classes
are stored.  We can queue requests to load multiple class files
asynchronously in the file system.

> Well,  this solution might not really help, if an application (or
> benchmark) only measures the period after VM is launched. (This is
> probably true since a Java timer can be triggered only after VM is
> created, unless the benchmark measures the duration of twice VM
> instance creations.)

Agreed, we should agree what we are optimizing, and why (the use case).

>>>> I assume we could improve that by consolidating that metadata into a
>>>> file with faster access.
>>> Yes, below is what Wenlong's patch includes.
>>> +# The modulelibrarymapping properties show class libraries in each module.
>> I saw that, but not sure which problem it is solving
>> (seek times/parsing/other).  Also, of course, this is a copy of the
>> metadata that we would need to keep in sync with changes to the module
>> manifests.  I'd like the best of both worlds :-)
> Right. A "better" solution I can think of is, the runtime can extract
> this information at build time or installation time. It can be the
> next step if we think it is a valid solution.

The OSGi frameworks must have this problem already.  They need to
maintain a cache of bundles installed in the runtime without it being a
surprise each time they start up.  While Wenlong's static cache is fine
for the prototype, there may be some code in Felix/whatever that we can
use to dynamically manage cached metadata for our modules.

p.s. Please don't take my comments as negative about the approach here.
 I'm delighted to see this type of innovative work taking place.


View raw message