harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Sun, 16 Nov 2008 09:10:26 GMT
Nathan,
This is a good question.

1. VM internal structutre caching gave 10% for helloworld app as early
prototypes showed [1].
2. Earlier jar loading optimizations gave 3% for the whole Eclipse
startup, and I expect further optimization to be less effective; they
are easier to start with because nearly no VM knowledge is required
[2].

Less accounatble facts in favour of caching are recent materials named
"booting windows/linux in 4 sec" and usefulness of reloadable vm state
dumps for QA.

With best regards, Alexei

[1] https://issues.apache.org/jira/browse/HARMONY-5513
[2] https://issues.apache.org/jira/browse/HARMONY-4569


On Sat, Nov 15, 2008 at 5:47 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> Can someone take the "maybe" out these statements and provide some proof?
>
> If this is true, then couldn't a quick hack be whipped up to package
> everything into various formats and show what the actual difference
> is.
>
> I'd like to see the actual difference before investing too much effort.
>
> -Nathan
>
> On Thu, Nov 13, 2008 at 9:30 PM, 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
>>>>>
>>>
>>
>



-- 
С уважением,
Алексей Федотов,
ЗАО «Телеком Экспресс»
Mime
View raw message