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
