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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
