harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [VM] On-demand class library parsing is ready to commit
Date Fri, 19 Dec 2008 16:42:35 GMT
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 <t.p.ellison@gmail.com> 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
>
>



-- 
С уважением,
Алексей Федотов,
ЗАО «Телеком Экспресс»
Mime
View raw message