Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 37715 invoked from network); 2 Feb 2007 08:55:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Feb 2007 08:55:37 -0000 Received: (qmail 12222 invoked by uid 500); 2 Feb 2007 08:55:35 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 12184 invoked by uid 500); 2 Feb 2007 08:55:35 -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 12175 invoked by uid 99); 2 Feb 2007 08:55:35 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2007 00:55:35 -0800 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 xiaofeng.li@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Feb 2007 00:55:26 -0800 Received: by ug-out-1314.google.com with SMTP id z36so613888uge for ; Fri, 02 Feb 2007 00:55:05 -0800 (PST) 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=ODrvCNYFCYpSqC7bXdJdz5EWETN8LcVwps7FnDbXsSeJ8nspm3Zd6JXgHgJt/icDSkc6bz4EFbCsQkDJi5GHxyhRe/Fv/BSYim7pz8q7KmSxJg8O8Y7ONZLUQyk17xaXhVHBx3jK1U78vMZIiXpS/Lb7p2T80UIdUDGlNx2Ne+w= Received: by 10.78.172.20 with SMTP id u20mr758875hue.1170406504465; Fri, 02 Feb 2007 00:55:04 -0800 (PST) Received: by 10.78.154.18 with HTTP; Fri, 2 Feb 2007 00:55:04 -0800 (PST) Message-ID: <9623c9a50702020055o6d58ce21s6b7c9269dd6800d3@mail.gmail.com> Date: Fri, 2 Feb 2007 16:55:04 +0800 From: "Xiao-Feng Li" To: dev@harmony.apache.org Subject: Re: [DRLVM] 64-bit support with compressed pointer In-Reply-To: <5ABFB0654C47814D94E6F2128D249BB4E1240E@ukhwex10.emea.bea.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9623c9a50702012149w588678f2x5ac5d0d7460625ec@mail.gmail.com> <5836de490702012233u298c2182qa674c9039d26abbe@mail.gmail.com> <9623c9a50702012330h1d3d58c4o291f18ca993de879@mail.gmail.com> <5836de490702020008n3c5535edy3f3b6f2f0fc099cd@mail.gmail.com> <5ABFB0654C47814D94E6F2128D249BB4E1240E@ukhwex10.emea.bea.com> X-Virus-Checked: Checked by ClamAV on apache.org Henrik, thanks for the link. I knew you guys got great number with compressed refs. I assume the figure 2 in that page shows performance of same configurations except for the processor bits. Probably the real power of 64bit is with large heap size. Henrik, does JRockit turn on the compressed pointer by default in 64bit platform? (if it's not confidential). Thanks, -xiaofeng On 2/2/07, Henrik Stahl wrote: > > We have this in 64-bit versions of BEA JRockit. See here for one > performance proof point: > http://e-docs.bea.com/jrockit/releases/5026x/relnotes/relnotes.html#wp10 > 79760 > > I guess the 13% number is close to the mark. It is app dependent, > though. > > -- Henrik > > > -----Original Message----- > > From: Aleksey Ignatenko [mailto:aleksey.ignatenko@gmail.com] > > Sent: Friday, February 02, 2007 9:08 AM > > To: dev@harmony.apache.org > > Subject: Re: [DRLVM] 64-bit support with compressed pointer > > > > I suppose there is no easy way to do that, but one can scan > > all places where > > > > #ifdef _EM64T_ appears and change appropriate places to > > something like #ifdef _COMPRESSED_MODE. Plus scan such places > > like gc_types.h in gc_cc, there is object header: > > VT32 vt_raw; > > unsigned info; > > You need to have VT64 vt_raw; for 64 bit mode. > > > > p.s. In some of discussions I read that compressed mode > > (comparing to uncompressed one) improved performance on about > > 13% on em64t. > > > > On 2/2/07, Xiao-Feng Li wrote: > > > > > Yes, that's exactly my question. I couldn't find an easy > > way to turn > > > off this compressed-ptr optimization. It's a little bit > > surprising me. > > > :-) > > > > > > Thanks, > > > xiaofeng > > > > > > On 2/2/07, Aleksey Ignatenko wrote: > > > > Did you check that it works on 64 bit mode with > > uncomressed references. > > > > I remember some time ago there were issues like hard coded > > > > compressed references used in JIT (or probably somewhere > > else) in 64bit mode. > > > > > > > > Best regards, > > > > Aleksey. > > > > > > > > On 2/2/07, Xiao-Feng Li wrote: > > > > > > > > > > Hi, current 64bit support uses compressed reference pointer by > > > > > default, i.e., a 64bit reference is stored as a 32bit > > value plus a > > > > > (global) base address. This can reduce the footprint of working > > > > > set and at the same time improve cache locality. But > > this has max > > > > > heap size limitation. > > > > > > > > > > I wonder why not use non-compressed pointer as by > > default, and the > > > > > compressed pointer is only an optimization that can be applied > > > > > when desirable. Comments? > > > > > > > > > > Thanks, > > > > > xiaofeng > > > > > > > > > > > > > > > > > > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. >