harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Thu, 13 Nov 2008 14:43:39 GMT
Some of those classes aren't HARMONY classes, they are ICU4J.

Is repackaging the only way to solve this issue?

On Thu, Nov 13, 2008 at 1:40 AM, 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?
>
> 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
>>
>

Mime
View raw message