I've seen this before on Windows boxes when initialising the JVM. There
appears to be a limit to the memory the JVM can address. The JVM version we
were using wouldn't start with -XMX much over 1.7GB as I remember.

However, this doesn't explain why you are seeing this when you shutdown
Tomcat.

On Windows, any *process* (not thread) is only allowed to allocate at
most 2GB of address space[0]. The JVM does not use any of the memory-
mapping tricks[1] necessary to access more than 2GB of RAM through a
smaller address space range, so the JVM, in turn, can allocate at most
2GB of RAM.  This includes the memory required to map in the JVM code
and to set up the stack, as well as the JVM's object heap and relevant
bookkeeping data.

So the most  RAM you can assign to the JVM on Windows is going to be
somewhat less than 2048 MB.

Note that this limit is per-process; thus, a machine with 32GB of
physical RAM is able to use all of it, but any one program can only
use at most 2GB of it.

Windows' in-process code and data occupies the "other" 2GB of the 4GB
32-bit address space.

[0] Or 3GB if Windows was started with the /3GB switch.  See <http://
blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx> for a very
thorough discussion of the tradeoffs involved.
[1] Shades of bank-switched memory...

Are you running a 32 bit or 64 bit JVM?

Patricia

First, what is the address space per task on that architecture. 2G 4G?
Consider also how much other junk fits in that address space, possibly
the OS, your code, your stacks.  There is precious little left for the
heap.

I think that in 32bit Solaris a process can be up to 4GB (I don't have any 32bit
Solaris boxes with sufficient memory to verify this), so a 2GB heap ought to be
ok. Are you using 32 or 64bit Solaris (I think the 240 can run 64bit), if it's
64bit then this is probably not the issue.

But, check your ulimit for virtual memory. That may be restricting the maximum
memory you are allowed to allocate.