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? + //rcSetProperty = (*vmInterface)->SetJarPackageMapping (vmInterface, jarName, jarValue); + /* + hymem_free_memory(jarName); + hymem_free_memory(jarValue); + */ Should we really commit the commented code? Thanks. 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 > > -- С уважением, Алексей Федотов, ЗАО «Телеком Экспресс»
