Re: how java reserves memory

devnew@gmail.com wrote:


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.

--
Lew