Wenlong Li wrote:
Regis,

Sorry for late response. The class preload and initialization happens
in vm_init.cpp, and totally around 270 classes are preloaded before
executing main() method.

We can pack preloaded classes in one jar, and leave other jars there.
The question is when requesting a new class, how do determine which
jar has it? In current implementation, we have to parse all jars to

Harmony modules division is based on the java package, so maybe a index could help this. for example, we could index all the package names begin whith java/javax/o.a.h and the bootstrap jar files, so we can quickly find which jar we should looking for.

load this class. That means, opening and closing all jars in classpath
is still unavoidable, and this time happens in running user code. In
contrast, the RI packs most classes in rt.jar, and totally four jars
are provided. I suppose RI also parses all classes in these four jars,
and read them into memory. Later when a class is reqired, a service of
providing class is made by looking up the pre-loaded classes in
memory.

In Harmony, it just parses all jars (totall more than 40) in
classpath, and reads all classes in these jars into memory. Later on
accessing a class, this data structure is scaned to define the
requested class. So current implementation is loading on-demand, but
has too many files to parse.
we parse all jars, but most of them may never be used. That would be great if we could parsing jars on-demand. And a another thought is, as you said, if remove some jars from bootstrap classpath, the startup time improve obviously, so is it possible to provide a vm option, like -Xpreload, to specify which boots jars should be parsed during startup time? And this option could not only speed the jvm startup, but also reduce the memory footprint.


Any comment?

Thx, Wenlong

On Tue, Nov 4, 2008 at 12:46 PM, Regis <[EMAIL PROTECTED]> wrote:

Wenlong Li wrote:
Hey, all,

I instrumented the Harmony startup module: Harmony VM creation in
JNI_GetCreatedJavaVMs of jni.cpp. This module is responsible for
creating VM, which includes classpath setting (jar file parsing and
handling), class loading & prepariing & initializing, compilation,
etc. In my test bed (2.8GHz Core 2 Quad-core, WinXP OS), Harmony will
take 170ms to creating VM in client mode (RI is much faster than
Harmony, but I don't have the exact number for its VM creation part).

For VM creation module, most time is spent in dll loading (in
vm_init1), classpath parsing and jar file processing (in
bootstrap_initial_java_classes), class file loading (basic and system
classes in preload_classes and initialize_system_class_loader], and
compilation (jet part).

To reduce the compilation time, I was wondering to postpone the
compilation phase, that means, can interpreter be used in startup
phase? I just compared the VM creation performance between client and
interpreter modes, and found interpreter is 20% faster than client
mode.

Another optimization in my mind is to reduce the disk I/O time, where
I could merge all jars into one big jar to provide .class file.
all-in-one jar may break the whole modular architecture. It's the one of the
most important features of Harmony that anyone can easily customize the
runtime, one big jar is hard to do it.
I didn't see the process of preload and initialize classes, and which
classes are required by vm startup, maybe we could pack these necessary
classes to a bootstrasp.jar, only load this jar when vm startup, other jars
could loaded on demand?
Another possible approach is to pre-load these jar files into disk
cache or memory (put all jars into /dev/shm directory under Linux OS).

What do you think? Any comments or suggestion are welcome and appreciated.

Thx, Wenlong


Reply via email to