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 <[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 >>>> >> > -- http://xiao-feng.blogspot.com
