On Wed, Nov 12, 2008 at 4:25 PM, Regis <[EMAIL PROTECTED]> wrote: > > 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.
It is a good idea to introduce an option. Thanks, xiaofeng >> >> 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 >>>> >> > -- http://xiao-feng.blogspot.com
