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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>> 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 >>>>> >>> >> > -- С уважением, Алексей Федотов, ЗАО «Телеком Экспресс»
