On May 31, 8:51 pm, "parminde...@gmail.com" <parminde...@gmail.com>
wrote:

I can only do some guesswork, but it should be like this: the heap is
the memory where the Java program running inside the VM may allocate
objects. Together with the stack, it limits the amount of memory the
Java program may consume. So, by using -Xmx (and -Xms), you may modify
this amount of memory; and judging from your description of JProf this
already works fine.
However, the virtual machine needs memory for itself - this should
include loaded class files, but may also contain hotspot-compiled
code, garbage collection data and such things. If your application is
really, really big (like a Spring web application which requires about
20 JAR files, each a few MB big) it does not seem too unlikely that
your VM requires so much memory.

There are OS-dependent ways of limiting the memory a single
application may consume. For Linux, using a csh shell gives you the
"limit" command (see "man csh" for the syntax) that allows you to
limit memory usage of any process. However, whether this will keep the
VM from crashing is another question; if it is just caching some data,
it may be forced to cope with the tighter memory limit, but if it
really needs memory that big, you are lost, as there is nothing you
can do (besides checking out other VM, like the BEA JRockit engine,
which might be a little more sensible towards those issues - but
again, I am just guessing.)

Regards,
 H.

One additional thing you might want to look out for.  If you have any
mixed language objects (i.e. Java objects which have underlying native
memory associated), when the object is created memory is allocated in
both the Java heap and the C native heap.  The Java heap is controlled
by the max heap size parameter, but the C memory is simply allocated
using malloc (and causes the JVM to grow).  Typically such objects have
a manual tidy method (often close()), with a fallback of object
finalisation.  It is important to explicitly call close() - otherwise if
the object gets promoted to the old area, the memory will not be freed
until the object gets garbage collected from the old area which can take
a very, very long time (and in the worst case you may have the process
hit a memory limit without a garbage collection occurring as only the
Java heap's behaviour will trigger garbage collection).

There are examples of such objects in the Java library (e.g. some of the
InputStream and OutputStream classes), as well as many 3rd party
libraries (e.g. I've seen it with database cursor implementations).

So in general, if a class has a close() type method, it must always be
explicitly called, and in a finally block (so that exceptions don't
cause leaked resources).

Cheers

Dave