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?


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