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 Mon, 17 Nov 2008 03:36:10 GMT
On Fri, Nov 14, 2008 at 8:24 PM, Regis <xu.regis@gmail.com> wrote:
> 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.

We can offer a build option to provide separate JARs if that's
desirable. Does anyone really need this feature?

Thanks,
xiaofeng

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



-- 
http://xiao-feng.blogspot.com

Mime
View raw message