On Sat, Dec 20, 2008 at 12:42 AM, Alexei Fedotov <[email protected]> wrote: > Wenlong, > Have I missed a discussion of the proposed design? I see that you > expose a new public interface: > /** > * @map the jar with exported package in the pending jar list for > on-demand jar parsing > * Key is the jar, and value is the package exported by this jar > */ > DECLARE_OPEN(void, vm_properties_set_pending_jar, (const char* key, > const char* value)); > > Did you mean "Maps" instead of "@map"? Strangely the word "pending" > disappeared from the name of the wrapping VMI interface > SetJarPackageMapping . Why should we extend both OPEN and VMI > interfaces with the same function? Why did you put your code into > working_classlib/modules/luni/src/main/native/luni/shared/luniglob.c, > thus introducing another dependency between VM and class library? [Wenlong] The boot class path is defined in luniglobal.c in Harmony, and it also has dependence with VM. In my understanding, my patch is related to boot class path determination, so I also put my code in luniglobal.c, and use VMI interface to communicate with VM.
> > + //rcSetProperty = (*vmInterface)->SetJarPackageMapping > (vmInterface, jarName, jarValue); > + /* > + hymem_free_memory(jarName); > + hymem_free_memory(jarValue); > + */ > Should we really commit the commented code? > Thanks. [Wenlong] Please see my latest version of patch in the list. Such commented code has been removed. > > > On Fri, Dec 19, 2008 at 6:59 PM, Tim Ellison <[email protected]> wrote: >> I was hoping that somebody else would comment first, so I don't have to >> be the grumpy one all the time :-) >> >> As I said before, this is good prototyping work... >> >> Wenlong Li wrote: >>> I did the pre-commit test on the patch of on-demand class library >>> parsing (https://issues.apache.org/jira/browse/HARMONY-6039), and it >>> works well now. >>> Can Harmony incorporate this feature? >> >> I'm not sure it is ready for committing to the head stream yet. >> >>> Via on-demand class parsing, we can reduce startup time from 20+ >>> seconds to 3 seconds for cold runing, and 170 ms to 140 ms for warm-up >>> running on Core 2 Duo with Windows. >> >> Can you tell me how to reproduce 20+sec cold start-up? I haven't seen >> anything like that in my simple tests. >> >>> After applying the patch, please note there is some change to add new >>> modules. >>> (1) If you want to add new modules/libraries, please don't put them in >>> the bootclasspath.properties file. This file now only saves modules >>> needed during startup (the VM startup only accesses class libraries in >>> eight modules) >> >> That would break too much. How about creating a new file rather than >> re-purposing an existing file with different semantics? This file is >> used by Jikes, IBM VME, the Eclipse plug-in, at least. >> >>> (2) For new modules/libraries, please put them in the >>> modulelibrarymapping.properties file. You should specify the module >>> name and its exported class library. Here is one example: >>> math.jar=java.math, where "math.jar" means the module name, and >>> "java.math" means the class libraries this module exports. >> >> As we discussed on another thread, its unclear if the time is spent in >> following the slow indexing through the classpath/JAR directories, or >> whether it is speed of loading bytes once we know what we need. I think >> that it is premature to abandon the JAR manifest data as the principal >> source of metadata until we understand the problem this solves. >> >> Can we measure where the time is spent in the current implementation? >> I think it will help guide this approach to a better solution. >> What tools do you recommend for profiling start-up? >> >> Regards >> Tim >> >> > > > > -- > С уважением, > Алексей Федотов, > ЗАО «Телеком Экспресс» >
