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 12:24:07 GMT
IMHO, it isn't negative to modularity of Harmony itself at developing 
time, but it is at deployment or runtime. For example, someone want to 
replace concurrent module with another implementation, he just need to 
replace the concurrent.jar, that's enough. But if we pack them into one 
big jar, he need to unpack, replace and pack again. That also work, but 
isn't convenient and straightforward.
In general, a jar means this is relatively independent module, could be 
removed or replaced if you want. If some jars are heavily coupled, it's 
better to pack them into one.

Best Regards,

Xiao-Feng Li wrote:
> Regis & Mingjian, would you explain why you think this approach is
> negative to modularity?
> Thanks,
> xiaofeng
> On Fri, Nov 14, 2008 at 11:30 AM, Regis <xu.regis@gmail.com> wrote:
>> 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.
>>>>>> think that would be one heuristics for us to decide parsing this
>>>>>> 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