Memory allocation is a bit complex in Java, and not always what you expect.
For one thing, it changes during the program run, because the optimizer
dynamically rewrites code as it happens.  It is possible for a memory
allocation to disappear altogether if the optimizer sees a way to do that.

The short version is that the JVM (Java Virtual Machine) reserves (allocates
from the operating system (OS)) a block of memory equal to at least the -Xms
value when it starts.  As memory needs in the programs grow, the JVM takes
more memory from the operating system, up to the -Xmx amount.  At that point
it needs to manage its own use more aggressively.

Inside the JVM, programs get their memory from the amount allocated by it from
the OS.  Typically a call to, say, "new MyFoo()" will allocate enough memory
from the Java heap to hold a MyFoo instance.  When no part of the program
refers to that object any longer, the garbage collector (GC) is allowed to
release the memory allocated to that object.

It's allowed to release it.  It's not required to release it.

Memory allocation is fast in Java, typically about ten machine instructions
(about 5 ns on modern processors).  De-allocation for about 95% of objects
costs nothing; garbage collection for most objects is only influenced by how
many are still alive, not how many are unreachable.

Whether primitive values go on the stack or not is up to the optimizer.  Many
might live in registers their whole lives.  It's conceivable the JVM could
decide to use the heap (if, say, autoboxing is involved).  As Java programmers
we do not get to say; it's up to the JVM.

Likewise with object allocation.  While we think of objects as living on the
heap, only, it's possible for the JVM to optimize that into register values,
too, under the right circumstances.

Unlike C# or other languages, the stack / heap dichotomy is not part of the
programming model in Java.

On Fri, 09 Nov 2007 01:43:19 -0800, "devnew@gmail.com"
<devnew@gmail.com> wrote, quoted or indirectly quoted someone who said

when a method is called, the stack pointer grows to allow room for all
the temporary variables in the stack frame.  Primitives typically take
1 32-bit slot. A reference to a object takes 32 bits in the usual JVM.
The object itself once allocated, lives on the heap.  In Jet,
optimisation sometimes puts objects themselves on the stack for speed.
This is transparent to your program.  It works to the program just as
if they were heap allocated.

You might find digging under the covers at how the JVM works as
fascinating as I do.  See http://mindprod.com/jgloss/jvm.html
http://mindprod.com/jgloss/jasm.html

On Fri, 09 Nov 2007 01:43:19 -0800, "devnew@gmail.com"
<devnew@gmail.com> wrote, quoted or indirectly quoted someone who said

Usually the term "reserving" is about the size of the entire Java app,
controlled by java.exe command line options.
see http://mindprod.com/jgloss/javaexe.html

The term "allocating" is about finding space for a single object.
http://mindprod.com/jgloss/garbagecollection.html