Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 8402 invoked from network); 2 Sep 2008 20:05:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Sep 2008 20:05:24 -0000 Received: (qmail 59117 invoked by uid 500); 2 Sep 2008 20:05:10 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 59093 invoked by uid 500); 2 Sep 2008 20:05:10 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 59082 invoked by uid 99); 2 Sep 2008 20:05:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Sep 2008 13:05:09 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 68.99.120.48 is neither permitted nor denied by domain of billdsd@gmail.com) Received: from [68.99.120.48] (HELO dukecmmtar01.coxmail.com) (68.99.120.48) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Sep 2008 20:04:11 +0000 Received: from [127.0.0.1] (really [68.105.254.142]) by dukecmmtar01.coxmail.com (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20080902200338.NWCC8636.dukecmmtar01.coxmail.com@[127.0.0.1]> for ; Tue, 2 Sep 2008 16:03:38 -0400 Message-ID: <48BD9C15.2030707@gmail.com> Date: Tue, 02 Sep 2008 13:03:33 -0700 From: Bill Davidson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Ignorance about some things. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Gregor Schneider wrote: > No, in fact the 64-bit-jvm is able to adress (thus use) more memory > than on 32-bit-jvm. > > just make sure that a 64-bit-jvm (java-virtual-machine) is installed. > Actually, in machine terms, pointers in a 64-bit system are twice as wide and thus take up twice as much space. Every reference is a pointer. Depending upon the machine implementation, even loops and conditionals could possibly use 64-bit pointers as well so those would use more memory if they did. So yes, a 64-bit system will always use at least somewhat more memory than a 32-bit system that does the same thing. This is not to say that there couldn't be a memory leak in the 64-bit JVM that doesn't exist in the 32-bit JVM. I'm just saying that all else being equal, the 64-bit version will use more memory -- because it has to. I remember when I was first playing with 64-bit systems in the mid 1990's (C/C++) and was surprised to find that many programs actually ran slower when recompiled for 64-bits. One of the reasons for that was because they're moving around more memory just to move their pointers around. Unless you have big memory and need big memory, or you're doing a lot of arithmetic with 64-bit integers, it's usually best to stay with the 32-bit version. It will usually be at least as fast if not faster and use less memory. Of course, if you need the big memory, or lots of 64-bit arithmetic then you need it so you go with 64-bit. As for the OP, you'll want to play around with -vmargs settings to your JVM. -Xmx is the obvious one. -XX:MaxPermSize is another less well known one that can help in many cases. PermGen space is one of those sneaky things they don't tell you about. You can set -Xmx really big and still have memory problems because not enough of it is available to PermGen. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org