Java Notebook: October 2012

Java Virtual Machine

A Java virtual machine is a program, which executes certain other programs, those containing Java bytecode instructions.

The JVM [Interpreter] translates bytecode to platform specific OS call, i.e. it act as the Middleman between bytecode and operating system. This makes Java a Platform Independent language.

JVM knows nothing of the Java programming language, only of a particular binary format, the class file format. Although the JVM is primarily aimed at running compile java programs, any language that can express in terms of valid class file can make use of JVM for execution

Each Platform [Windows, Linux] has a JVM written specifically for it, JVM implementation can come from many vendors [Oracle, IBM, etc..] but it should adhere to the JVM Specification

Once JVM Implementation is installed, we will be able to run/execute java application/class which will inturn give rise to a JVM instance.

So now we understood the term "JVM" could denote either

a)     The Abstract Specification

b)     A Concrete Implementation

c)     A Runtime Instance

JVM Instance

When a java application starts, JVM instance is born and it dies when the program ends. i.e., if you are running three java programs, then that mean there are three JVM instances running.

Each JVM instance is born with a Method Area and one Heap. Both these areas are shared across the threads within the JVM instance. These are not thread safe.

Heap: Memory where all objects, global variables resides

Method Area: This is the area where the bytecodes reside. It has all the instructions which needs to be executed.

When a new thread comes into existence, it gets its own PC register (program counter) and Java stack. No thread can access the PC register or Java stack of another thread. These are thread-safe!

Java Stack: This stores the state of method invocations, where the state includes the in progress methods, local variables [primitive / reference variable], method arguments, and return value

PC Register: This points to some byte in the method area. While a thread is executing a method, the value of the pc register indicates the next instruction to execute.

How does Java Stack track the state of method invocation?

Java Stack is composed of stack frames. A stack frame contains the state of one Java method invocation. A new frame is created on top of stack each time a method is invoked, and it is removed when the method completes. Only one frame [current executing method] is active at any point in a given thread of control.

Runtime data area

Where

a) Method Area & Heap are shared across threads

b) Stack and PC Register are created for each thread, no thread can access other’s stack or pc register

c) Stack refer to the object available in heap

d) PC register points to some byte in the method area

e) Highlighted Frame2 is the active frame

JVM Execution Demonstration

Assume Class ExecDemo has two methods [1 & 2], where method1 calls method2, method2 creates a new instance for A which in turn hold reference of B

Below figure show how the Java Stack, Frames and Heap memory are constructed for the above program, please note that since it is single thread we have only one Stack.

The top highlighted method2 frame is active frame [current menthod invoked]

Method1 Frame

a) Creates local variable in stack

b) Invoke method2

Method2 Frame,

a) Instance of A along with dependent object B will be created in heap

b) Reference of A will be created in stack

When method2 execution is completed, the method2 frame will be removed from Stack and control will go back to method1 also since Object A [Heap] is no where referenced it will be available for garbage collection

Garbage Collection:

A garbage collector's job is to automatically reclaim the memory used by objects that are no longer referenced by the running application.

Garbage Collection happens only in Heap memory, Java Stack does not require Garbage Collection as the stack frames [holds local variables] will be removed when method is completed

No garbage collection technique is dictated by the Java virtual machine specification. Designers/JVM Implementors can use whatever techniques seem most appropriate for them.

My initial thought was to write an article on Garbage collection but later felt a basic understanding on Heap memory is essential and hence I ended up with this article. Please watch out for my next article hopefully it will be on garbage collection.

Points to Remember:

Instances are created in Heap
Stack stores state of the method invocation includes local variables [primitive and reference], arguments, and return type
The stack is threadsafe (each thread will have its own stack) but the heap is not threadsafe
If the computation in a thread requires a larger Java virtual machine stack than is permitted, the Java virtual machine throws a StackOverflowError.
If a computation requires more heap than can be made available by the automatic storage management system, the Java virtual machine throws an OutOfMemoryError.
Although the same runtime data areas exist in some form in every Java virtual machine implementation, the JVM specification is quite abstract. Many decisions about the structural details of the runtime data areas are left to the designers of individual implementations