harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [vm] Implement on-demand class library parsing to avoid unnecessary jar/zip parsing during startup (HARMONY-6039)
Date Thu, 11 Dec 2008 02:12:14 GMT
I like the proposal, but I'd like to see an addition that either
negates the duplication of manifest information or automates the
generation of it. The later may be easiest - add a bit to the build
that reads the manifests and generates the file.


On Wed, Dec 10, 2008 at 8:22 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 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
>>>>>> 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
> --
> http://xiao-feng.blogspot.com

View raw message