From dev-return-35350-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Fri Nov 14 05:55:29 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 68212 invoked from network); 14 Nov 2008 05:55:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Nov 2008 05:55:28 -0000 Received: (qmail 94683 invoked by uid 500); 14 Nov 2008 05:55:33 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 94659 invoked by uid 500); 14 Nov 2008 05:55:33 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 94648 invoked by uid 99); 14 Nov 2008 05:55:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2008 21:55:33 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com designates 209.85.200.169 as permitted sender) Received: from [209.85.200.169] (HELO wf-out-1314.google.com) (209.85.200.169) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Nov 2008 05:54:13 +0000 Received: by wf-out-1314.google.com with SMTP id 28so1210383wfc.24 for ; Thu, 13 Nov 2008 21:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=RB353Fo59QyXdDH6O949UhBWwr6KrCDAamoLqHWYqBE=; b=s2MdW+X8dyavaxjR7LtWT64i6nF59P5U4g48Iu+TZl5Vx/8rq8OjyhxhmnLajcKsM9 IKrjHPHKo+J1Tun+CLNIeAUtNbKyUjqkNmSnxsC//WyyPvvWR+rP1fBvnsrqk+5kpg5x BMLxFri60mrTRdclXw4Gvi3LWlzIMTYdsRZEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=CgaqnmzSKIo2BwHRdyv/BRBPOfJew7shlEMn+n1Z6O0/2ctCsMMG9tXMPCWqyQkwAx xZjCCF78PrsP4Qxc68LjS7i5j0uS8zgt/9KJ7XDxoOSVZ7Bu3Z5sagKR3IIQh+r0mAbx 44QyxVV00Upx/KOVG+o/JYgC99NU1mL+xufnc= Received: by 10.143.166.10 with SMTP id t10mr229404wfo.210.1226642087160; Thu, 13 Nov 2008 21:54:47 -0800 (PST) Received: by 10.143.164.5 with HTTP; Thu, 13 Nov 2008 21:54:47 -0800 (PST) Message-ID: <9623c9a50811132154i1b43942cx60653a55696f9cc2@mail.gmail.com> Date: Fri, 14 Nov 2008 13:54:47 +0800 From: "Xiao-Feng Li" To: dev@harmony.apache.org Subject: Re: [performance] Startup cost is high for Harmony (HARMONY-6002) In-Reply-To: <491CF0C3.3010008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490FD389.9000405@gmail.com> <9623c9a50811120009l44dbca4embec5bc1b32bb208d@mail.gmail.com> <491AFABD.2070209@gmail.com> <3b3f27c60811130643v27e44143xd58d7c88a915ac63@mail.gmail.com> <491CF0C3.3010008@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Regis & Mingjian, would you explain why you think this approach is negative to modularity? Thanks, xiaofeng On Fri, Nov 14, 2008 at 11:30 AM, Regis wrote: > If we could reduce the number of pre-load jars from 40+ to 12 (listed on the > JIRA), maybe I/O for loading jars is no longer a big bottleneck, while the > less, the better :) > I just mean a careful trade-off needed between performance and modularity. > > Best Regards, > Regis. > > Nathan Beyer wrote: >> >> Some of those classes aren't HARMONY classes, they are ICU4J. >> >> Is repackaging the only way to solve this issue? >> >> On Thu, Nov 13, 2008 at 1:40 AM, Wenlong Li wrote: >>> >>> Agree. >>> >>> Hello, all, >>> I collect the required classes/packages/jars in >>> http://issues.apache.org/jira/browse/HARMONY-6002. As we discussed, we >>> can package these classes into the bootstramp.jar, and handle other >>> classes/jars on demand. >>> >>> In my mind, we can parse all jars at startup, and only save the >>> manifest of each jar (except bootstramp.jar with all jars loaded >>> during startup). Later, when a new class is required, we can parse the >>> manifest to see this class in which jar, and then read all classes in >>> this jar to class cache (because I/O is also expensive, so I think we >>> should read all classes in this jar). As for implementation, I think >>> we can add code in LoadFromJarFile of classloader.cpp to support >>> on-demand jar/class parsing and loading. Is my understanding correct? >>> One more question is how to generate bootstramp.jar automatically? At >>> this moment, we can manually produce it, but it doesn't make sense for >>> a product. I guess we need make some modification on the modularity >>> under working_classlib\modules >>> >>> What do you think? >>> >>> Thx, >>> Wenlong >>> >>> On Wed, Nov 12, 2008 at 11:48 PM, Tim Ellison >>> wrote: >>>> >>>> Wenlong Li wrote: >>>>> >>>>> Yes, I also noticed the manifest in each jar has keyword, like >>>>> export-package to define which packages are provided by this jar. I >>>>> think that would be one heuristics for us to decide parsing this jar >>>>> or not. I will try to add the on-demand jar parsing feature into >>>>> Harmony by using this rule information. >>>> >>>> Good idea. Or introduce the concept of a start-up classpath ... so you >>>> don't have to hard-code in the VM which packages are in the start-up >>>> sequence. >>>> >>>> Right now there is the bootclasspath and application classpath. We >>>> expect all the start-up classes plus more to be on the bootclasspath. >>>> >>>> But if we split that into the bootclasspath={start-up path + system >>>> path} classes then we can preload / process the JARs on the start-up >>>> classpath, and defer the parsing of those on the system classpath. Just >>>> as a start-up differentiator, the start-up+system JARs would of course >>>> all be part of the bootclasspath to the application. >>>> >>>> Just an idea... >>>> >>>> Regards, >>>> Tim >>>> >> > -- http://xiao-feng.blogspot.com