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: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Thu, 13 Nov 2008 08:07:15 GMT
On Thu, Nov 13, 2008 at 3:40 PM, Wenlong Li <wenlong@gmail.com> wrote:
> Agree.
> Hello, all,
> I collect the required classes/packages/jars in
> http://issues.apache.org/jira/browse/HARMONY-6002. As we discussed, we
> can package these classes into the bootstramp.jar, and handle other
> classes/jars on demand.
> In my mind, we can parse all jars at startup, and only save the
> manifest of each jar (except bootstramp.jar with all jars loaded
> during startup). Later, when a new class is required, we can parse the
> manifest to see this class in which jar, and then read all classes in
> this jar to class cache (because I/O is also expensive, so I think we
> should read all classes in this jar). As for implementation, I think
> we can add code in LoadFromJarFile of classloader.cpp to support
> on-demand jar/class parsing and loading. Is my understanding correct?
> One more question is how to generate bootstramp.jar automatically? At
> this moment, we can manually produce it, but it doesn't make sense for
> a product. I guess we need make some modification on the modularity
> under working_classlib\modules
> What do you think?

As a simple solution, can we package the bootstrap.jar in deployment
time? I mean, to generate it as a step of build.

> Thx,
>  Wenlong
> On Wed, Nov 12, 2008 at 11:48 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Wenlong Li wrote:
>>> Yes, I also noticed the manifest in each jar has keyword, like
>>> export-package to define  which packages are provided by this jar. I
>>> think that would be one heuristics for us to decide parsing this jar
>>> or not. I will try to add the on-demand jar parsing feature into
>>> Harmony by using this rule information.
>> Good idea.  Or introduce the concept of a start-up classpath ... so you
>> don't have to hard-code in the VM which packages are in the start-up
>> sequence.
>> Right now there is the bootclasspath and application classpath.  We
>> expect all the start-up classes plus more to be on the bootclasspath.
>> But if we split that into the bootclasspath={start-up path + system
>> path} classes then we can preload / process the JARs on the start-up
>> classpath, and defer the parsing of those on the system classpath.  Just
>> as a start-up differentiator, the start-up+system JARs would of course
>> all be part of the bootclasspath to the application.
>> Just an idea...
>> Regards,
>> Tim


View raw message