Can I my -Xmx option be as high as 256M?

On most JVMs. Test it out for your JVM. On Sun's Windows 1.3 JVM I get variously:
1024M works
<PRE>
c:\java\jdk1.3\bin\java.exe -Xmx1024M
Usage: java [-options] class [args...]
(to execute a class)
or java -jar [-options] jarfile [args...]
(to execute a jar file)
...
</PRE>
2048 doesn't
<PRE>
c:\java\jdk1.3\bin\java.exe -Xmx2048M
Invalid maximum heap size: -Xmx2048M
Could not create the Java virtual machine.
</PRE>
2047 gives an interesting failure
<PRE>
C:\>c:\java\jdk1.3\bin\java.exe -Xmx2047M
Error occurred during initialization of VM
Size of maximum heap (-2147483648 bytes) must be aligned to 2097152 bytes
</PRE>
--Jack Shirazi http://www.JavaPerformanceTuning.com/

But bear in mind that you should always keep Mx some way below your actual max RAM, or any other processes will cause the JVM to start swapping - which is bad.

*Theoretically* does that mean if I were to have 1 GB of RAM and HotSpot JVM was the only thing installed on that machine, I could specify it to go as high as 0.75 GB?
Is there an upper limit on the RAM that the JVM itself can borrow even though the OS is ready to give that RAM?
I am not very familiar with memory issues so pardon my ignorance on some of these issues. :-)

Originally posted by Frank Carver:
But bear in mind that you should always keep Mx some way below your actual max RAM, or any other processes will cause the JVM to start swapping - which is bad.

Do I misunderstand how these flags work? I thought the JVM will grow its heap to the maximum setting only when necessary. Surely some swapping is preferable to an OutOfMemory error?
- Peter

Yes, it will grow it only when necessary, but what happens when it does?
I may be wrong, but I think the missing factor is the Garbage Collector. If your system has a fair amount of object churn (and most Java software does), then a large heap will tend to accumulate lots of objects awaiting GC. Now, if some of this heap has to be swapped out, then when it comes to be Garbage Collected the Garbage Collector can really thrash the swapping mechanism, which is a huge performance hit.
As a rule, I don't think you should really run Java software which is too big for physical RAM unless there is no other way, and you are prepared to take a massive thrashing hit. Setting the max heap size to less than the physical limit is an effective way to ensure this doesn't happen accidentally.

Originally posted by Frank Carver:
I may be wrong, but I think the missing factor is the Garbage Collector. If your system has a fair amount of object churn (and most Java software does), then a large heap will tend to accumulate lots of objects awaiting GC.

I see the point. Yet one would hope that a generational garbage collector would behave much better in this regard... it would be interesting to try it out with a modern JVM?
- Peter