Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=B7Ib6YJd/avjjT1u2EeyMiPKF8+tD28f3tvH2Hj78F4XEYSItRwnT2Mwh64HvvOoVl
         k3noGiP8gu3vLW/ZAWRHvSv/PGidAKRGUZRM6OPGO2OWDzjW7hitFohS9PzBEQjny7Mz
         EGbk1CAw4o9KdkX3CMuwvnpW+eSUlTpIwbATA=
Message-ID: <9623c9a50812100541r663c21des2a2ab98a871a701d@mail.gmail.com>
Date: Wed, 10 Dec 2008 21:41:57 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [vm] Implement on-demand class library parsing to avoid
 unnecessary jar/zip parsing during startup (HARMONY-6039)
In-Reply-To: <493FC000.6010708@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1682519387.1228881884465.JavaMail.jira@brutus>
	 <493F9EE6.8010704@gmail.com>
	 <9623c9a50812100450y10af157egb7938cde50872781@mail.gmail.com>
	 <493FC000.6010708@gmail.com>

On Wed, Dec 10, 2008 at 9:11 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Xiao-Feng Li wrote:
>> On Wed, Dec 10, 2008 at 6:50 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> This is cool.
>>>
>>> Wenlong Li (JIRA) wrote:
>>>> During VM creation, Harmony will parse all class libraried defined in
>>>> bootclasspath.properties under jre/lib/boot directory. However, not
>>>> all class libraries are accessed during startup. That means, it is
>>>> not necessary to open and resolve all these class libraries.
>>> Agreed.
>>>
>>>> In this patch, I implement the on-demand jar parsing. I leverage the
>>>> class library info defined in the manifest file of each module. For a
>>>> request class, if it is not available in existing class table, I then
>>>> parse its class library info, and check which module contains this
>>>> requested class. That is, I parse the class library on demand.
>>> Its good to see the manifest information being used at runtime.
>>>
>>> So as I understand it, you are not looking to provide any isolation
>>> between modules, just using the metadata to direct the search path.
>>>
>>>> Using on-demand class library parsing, I can reduce the VM creation
>>>> time from 20+ seconds to 3 seconds.
>>> Wow, that's remarkable.  Is ZIP file directory performance really that bad?
>>>
>>> I'm assuming that it is multiple VM creations (it doesn't take 20s to
>>> invoke the VM usually!)  And that is still opening and reading the
>>> manifest from each JAR?
>>
>> Cold start (first time launch) and warm start (not first time launch)
>> have very different numbers, because of the disk access caching
>> effect. The numbers in seconds should be cold start. I remember in
>> Wenlong's data given early, this work can improve the warm start time
>> as well, something like from 170ms to 140ms.
>
> Luckily, I've never seen a 20s start up time.
>
> 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.
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.)

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

Thanks,
xiaofeng

> Regards,
> Tim
>


-- 
http://xiao-feng.blogspot.com