From dev-return-35635-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Fri Dec 12 16:23:30 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 5841 invoked from network); 12 Dec 2008 16:23:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Dec 2008 16:23:30 -0000 Received: (qmail 28055 invoked by uid 500); 12 Dec 2008 16:23:42 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 28028 invoked by uid 500); 12 Dec 2008 16:23:41 -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 28017 invoked by uid 99); 12 Dec 2008 16:23:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2008 08:23:41 -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.146 as permitted sender) Received: from [74.125.92.146] (HELO qw-out-1920.google.com) (74.125.92.146) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2008 16:23:21 +0000 Received: by qw-out-1920.google.com with SMTP id 4so327779qwk.24 for ; Fri, 12 Dec 2008 08:23:00 -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=AKvr7Q4Ha2fvqrFBWlS/xvqU252O4bno+zncUCdFRa4=; b=o4HkNBNqHhmJ9HT3sf0iPL7QbNjtZ/aeSrqz8sTob6QTj45SzkGhFrX4gp+ZWZd8Mo d6HsYCxdA6vEw3A2iQk1UqNTVUVf+ZEp0Hc4SYW+YO+xJ1hHxh+MLhJm1iBlkr1slGYi OOQnkEHZpTmj9oBb+/np3uuMTr4oRk5FlgvYM= 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=O1w9w8cCR81Xv+bERfaQT5iMg2nJ9AHpayMg7LuSrEA6hWFjT41IFBfoWgu1dWhS4Z MCGemWJbnGNR5hLcnJyYo2YicpdkyN4gZg8122h8u6prpmngZBPFI5rcFetjvhLxnBBo ilmSlIgfjLbtZb5feeul9Dw2ahMAet1k9WbXM= Received: by 10.215.38.3 with SMTP id q3mr5370473qaj.336.1229098980557; Fri, 12 Dec 2008 08:23:00 -0800 (PST) Received: by 10.214.181.9 with HTTP; Fri, 12 Dec 2008 08:23:00 -0800 (PST) Message-ID: Date: Sat, 13 Dec 2008 00:23:00 +0800 From: "Wenlong Li" To: dev@harmony.apache.org Subject: Re: [vm] Implement on-demand class library parsing to avoid unnecessary jar/zip parsing during startup (HARMONY-6039) In-Reply-To: <49428C56.2000408@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1682519387.1228881884465.JavaMail.jira@brutus> <493F9EE6.8010704@gmail.com> <9623c9a50812100450y10af157egb7938cde50872781@mail.gmail.com> <493FC000.6010708@gmail.com> <9623c9a50812100541r663c21des2a2ab98a871a701d@mail.gmail.com> <493FCD12.7040909@gmail.com> <9623c9a50812100622w36106b51n1dd347836a3bff8b@mail.gmail.com> <3b3f27c60812101812g48c7b3efi54f346c4db3612a4@mail.gmail.com> <49428C56.2000408@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Tim, I didn't spend more efforts to collect trace. Based on my experiment, reducing the number of loaded byte can help performance. Reducing the loading of zip can also help performance. But I don't collect exact performance data for each. Also adjusting the layout of zip in consecutive disk can also help performance. As I have reduced the VM creation time from 20+ seconds to 3 seconds on my windows machine, I suppose there would be small benefit when taking other approaches. But I believe they would help performance as you pointed out. Thx, Wenlong On Sat, Dec 13, 2008 at 12:07 AM, Tim Ellison wrote: > Wenlong Li wrote: >> The performance of on-demand library parsing is mostly from I/O (seek >> the jar, open the jar, read content for each class in the jar, etc). >> When disk cache is warm-up, the I/O impact is small, and then we see >> small performance improvement. > > Ok, so that says that better indexing of the bytes we need to load on > start-up won't necessarily help. We need to reduce the number of bytes > we load, or optimize the layout to help the loading speed up, right? > > Or do you mean the time is spent loading the ZIP directories (rather > than class file bytes)? > > Do you have some trace that shows what's happening? > >> You see the bootclasspath property is pre-defined in >> working_classlib\depends\files, so I pre-define another property file >> which saves the class library info for each package. I assume the >> library in each module will not change over time, just like the >> bootclasspath property file. Of course, when new module is added, we >> need update these properties. Question is how Harmony revises the >> bootclasspath property now? > > It is defined by parsing the bootclass.properties file. > >> I will think about how to automatically extract the package info from >> manifest of each module, and save them in my defined property file at >> compiling time. >> >> Suggestion and comments are welcome and appreciated. :) > > Don't bother yet :-) Seriously. > > If you say that the time is taken to seek and read the bytes for the ZIP > file directory... > ...then why stop at building the index to show where packages are? > ...why not build a full class level index? > > If you are saying that the time is spent loading the actual class files > from disk, and not parsing the ZIP directory entries to search for the > location of the bytes then this won't help and we need to layout the > bytes in a way that optimizes for start-up reading - or allow overlapped > reading and defer to the OS - or ? > > Regards, > Tim > >