harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@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:22:03 GMT
On Wed, Dec 10, 2008 at 10:07 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> 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.

Agreed. This kind of dynamic Felix-based way probably will be a long
term ultimate solution.

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

Definitely not negative. Comments are always welcome. And I think
Harmony community needs more comments. :)

> Regards,
> Tim


View raw message