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 Fri, 14 Nov 2008 05:54:47 GMT
Regis & Mingjian, would you explain why you think this approach is
negative to modularity?


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. 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