Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 3530 invoked from network); 13 Nov 2008 07:41:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Nov 2008 07:41:16 -0000 Received: (qmail 84968 invoked by uid 500); 13 Nov 2008 07:41:22 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 84940 invoked by uid 500); 13 Nov 2008 07:41:22 -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 84929 invoked by uid 99); 13 Nov 2008 07:41:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Nov 2008 23:41:22 -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 wenlong@gmail.com designates 74.125.92.147 as permitted sender) Received: from [74.125.92.147] (HELO qw-out-1920.google.com) (74.125.92.147) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Nov 2008 07:40:03 +0000 Received: by qw-out-1920.google.com with SMTP id 4so492616qwk.24 for ; Wed, 12 Nov 2008 23:40:36 -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=OzTeldPcZTtf7XYh++m8RhzuYifv9ATNPB3Pz7Mk7Q4=; b=PWupj9ba92P6IXuQVsy+tX98R9mEF0gSbmweVtqx5pb0k4scdP1ORu67q/QMLAKtZQ NO8RywAsu155HFCNDxx4Oi+L//i2YvQHDWhNltbeKdodqwd9XsO5G5Bc1z5ragNsgfJX CmLhgtvylQMafkJgg8QTugOmYyZh0rG/VNw+E= 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=AxSRu9ODNfAmbIOkmgl25zFOnHJEx5MVO0XgloWv1xO8rSJ2A1ZAU7ePVCncUcZ52F +kWRIm/Di/MTxY8DMy4MCIkLmsGSCjLIRTby5kES1UKJUqVktun0eKj85MTc5fZszPnS 1JS61tPesANCEfstB98jm21l2Rjhf6YOEVJdc= Received: by 10.214.59.5 with SMTP id h5mr10785460qaa.187.1226562036762; Wed, 12 Nov 2008 23:40:36 -0800 (PST) Received: by 10.214.116.8 with HTTP; Wed, 12 Nov 2008 23:40:36 -0800 (PST) Message-ID: Date: Thu, 13 Nov 2008 15:40:36 +0800 From: "Wenlong Li" To: dev@harmony.apache.org Subject: Re: [performance] Startup cost is high for Harmony (HARMONY-6002) In-Reply-To: <491AFABD.2070209@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> X-Virus-Checked: Checked by ClamAV on apache.org 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 >