From dev-return-27048-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Thu May 17 08:01:48 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 44211 invoked from network); 17 May 2007 08:01:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 May 2007 08:01:47 -0000 Received: (qmail 78788 invoked by uid 500); 17 May 2007 08:01:51 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 78761 invoked by uid 500); 17 May 2007 08:01:51 -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 78752 invoked by uid 99); 17 May 2007 08:01:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2007 01:01:51 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of evgueni.brevnov@gmail.com designates 66.249.82.238 as permitted sender) Received: from [66.249.82.238] (HELO wx-out-0506.google.com) (66.249.82.238) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2007 01:01:44 -0700 Received: by wx-out-0506.google.com with SMTP id i26so471864wxd for ; Thu, 17 May 2007 01:01:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lKTSx5Nh3C0z0TgMH72m2url3EP0awnpSP95sX9siHoNOQAwHW0KwkqrQ8OXFxtooJmDUUtxjsj0f3Zna8m/OvbXMtikzn26wrRs0+y6I6TlS8kpPjM7q7Hc0Od9dkbJBeqOtqFasQKF8E6gFLAqs9JxShTPibpa+Tb9eF5MS0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kVf7OdLKC0ARw+OUm/ldyQPXhFirep8JUXKz9LK3GmmjrFfDtIOIYR43p+VXWqCw8gLht2JQ5uE3yOY6wwg+E6Rf258dxYSKoDx+cyaSDSKbXmBPU1yfnWLsEYVIJ58Sj1KH9rxxykPsRyhHD9sGgIjUd4fgFihQDTyNRg0gyAM= Received: by 10.78.170.17 with SMTP id s17mr16632hue.1179388882647; Thu, 17 May 2007 01:01:22 -0700 (PDT) Received: by 10.78.48.19 with HTTP; Thu, 17 May 2007 01:01:22 -0700 (PDT) Message-ID: Date: Thu, 17 May 2007 15:01:22 +0700 From: "Evgueni Brevnov" To: dev@harmony.apache.org Subject: Re: [drlvm][performance] VM properties implementation is inefficient In-Reply-To: <5ce835490705160529i39349956ib7c58c32591f64b8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ce835490705100951t46c12fbdqdd4185547343aee9@mail.gmail.com> <5ce835490705110405x33221885lb0fdc6158d7a22ee@mail.gmail.com> <90aafe1d0705110951j34701e4ch457ab6aafcd63af1@mail.gmail.com> <5ce835490705111041o5986d1e9pc594a6de5b836d67@mail.gmail.com> <5ce835490705160529i39349956ib7c58c32591f64b8@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 5/16/07, Ilya Berezhniuk wrote: > Alexey! > > Thanks for idea, I agree that adding getters to Properties class can be a > best solution. > I'll try to implement this approach and check performence. > > Regarding caching flag in verifier: unfortunately, verifier must read this > flag every time and cannot cache it, because corresponding property can be > changed by uncontrolled code. Probably I miss something here but why we should read the property each time? We can just have a special flag indicating that property has changed and its cashed value must be updated. Thanks Evgueni > > 2007/5/16, Alexey Varlamov : > > > > 2007/5/12, Ilya Berezhniuk : > > > Thank you, Rustem! > > > > > > I was wondered with these results too. It's my fault; I actually used > > > default heap size for SPECjbb. > > > > > > It means that real gain is much lower. > > > But if these modifications affect native part only, and its effect is > > > significant, I think it can be reasonable anyway. > > > > > > > > > Evgueni, > > > > > > One of hotspots I've found is using properties is verifier. It checks > > > verifier flags every time when invoked. > > > > Shouldn't we fix the verifier then - to cache flags or such? > > My point is that properties have established and safe interface now, > > and see no persuasive reason to change it. Of course it is possible to > > optimize impl - say, by using specialized allocator instead of malloc, > > or enrich Properties class with get_boolean()/get_int() members to > > avoid intermediate copying in some cases (currently this is part of VM > > C interface impl with extra overhead). > > > > > AFAIK, the count of properties is incomparably fewer than count of > > strings > > > parsed from class constant pools. > > > And loader_env->string_pool is already used to store constant strings, > > the > > > names of loaded libraries in natives support for example. > > > > I second Evgueni here, using String_Pool for collecting everything is > > undesirable - this is quite stressed storage, we rather should try to > > reduce overhead on it. > > > > -- > > Alexey > > > > > > > > > > > 2007/5/11, Rustem Rafikov : > > > > > > > > Hi All, > > > > > > > > Indeed, ~95% of time we spend in jitted code when running jbb2005. > > > > Other %% are spreaded among native code, no one module takes > 2-3%. > > > > > > > > I've just cheked the patch on jbb2005 @ win32 (prescott and woodcrest, > > > > both > > > > gvc4.1 and gcv5) and linux64 (woodcrest, gcv4.1). > > > > 1.5G heap was used. No boost has been measured. All difference is in > > > > uncertainty range (< 1%). > > > > > > > > An assumption may be that 2.41% boost was measured with default heap > > size > > > > and impact of native code was higher in this case. > > > > > > > > -- > > > > Thanks, > > > > Rustem > > > > > > > > > > > > > > > > -- > > > > > > Ilya > > > > > > > > > -- > > Ilya >