harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Thu, 06 Nov 2008 08:25:44 GMT

The idea just came to my mind, that we can do two simple things:
1) Order jars by the probability of using classes from these jars
(classes from some jars are never used during many scenarios - even
some heavy ones such as application servers);
2) Postpone parsing internal jar structure up to the first time the
jar is reached in bootclasspath.

Example: assume we have following bootclasspath: kernel.jar;luni.jar;other.jar.
Many applications may require classes only from first two jars. In
this case there is no need to parse the structure of the third jar
file. It will only be parsed on first class which won't be found in
first two jars.


On Thu, Nov 6, 2008 at 4:13 AM, Wenlong Li <wenlong@gmail.com> wrote:
> All,
> Thx for all your nice comments and suggestion.
> Before trying your suggestion, here I would like to share some
> findings, and expect your thoughts.
> (a) As all jars reside in disk, the expensive I/O is a problem. For
> example, the first run takes 876 ms to create VM, while the following
> run takes only 170 ms. I think this is due to the disk cache warm-up
> problem. I did another experiment on Linux machine, where I put the
> all jars in the /dev/shm directory. We saw the first run has the same
> performance as the following runs, indicating pre-loading the data
> into memory or disk cache can speed up startup.
> (b) The bootclasspath.properties in lib/boot directory defines what
> jars will be parsed and loaded during startup. I just removed some
> jars, and found the startup time can be further reduced from 170 ms to
> 140 ms for the run with warm-uped disk cache.
> (c) As the compilation time is also high in client mode, I use the
> interperter mode to run the program, and found the time can decrease
> from 140 ms to 94 ms.
> Any thought?
> Thx, Wenlong
> On Thu, Nov 6, 2008 at 12:45 AM, Mark Hindess
> <mark.hindess@googlemail.com> wrote:
>> In message <bdbaeccd0811031931o16ab41c5oeac5a8f2f0140d92@mail.gmail.com>, "Wenl
>> ong Li" writes:
>>> Another optimization in my mind is to reduce the disk I/O time, where
>>> I could merge all jars into one big jar to provide .class file.
>>> Another possible approach is to pre-load these jar files into disk
>>> cache or memory (put all jars into /dev/shm directory under Linux OS).
>>> What do you think? Any comments or suggestion are welcome and appreciated.
>> As Regis says we probably don't want to break the modularity to solve this.
>> Perhaps we can learn something from the "Booting Linux in five seconds"[0]
>> work.  They use sReadahead to do all the I/O up front[1] maybe there is a way
>> we do something similar for the "blocks" read on startup?
>> Regards,
>>  Mark.
>> [0] http://lwn.net/Articles/299483/
>> [1] Actually not upfront but using in an "idle" I/O scheduler but this isn't
>>    really an option for us.

View raw message