harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Fri, 14 Nov 2008 03:30:11 GMT
If we could reduce the number of pre-load jars from 40+ to 12 (listed on 
the JIRA), maybe I/O for loading jars is no longer a big bottleneck, 
while the less, the better :)
I just mean a careful trade-off needed between performance and modularity.

Best Regards,
Regis.

Nathan Beyer wrote:
> 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