harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Wed, 12 Nov 2008 08:25:03 GMT

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 <xu.regis@gmail.com> 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

View raw message