JVM View

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

References:

The Java™ Virtual Machine Specification

http://docs.oracle.com/javase/specs/jvms/se7/html/index.html 

The Java Virtual Machine by Bill Venners

http://www.artima.com/insidejvm/ed2/jvm.html

http://viralpatel.net/blogs/java-virtual-machine-an-inside-story/

An Exception View

Wikipedia Definition on Exception:

An action that is not part of ordinary operations or standards

From the definition it is clear that exception doesn’t mean error. In our day today life there are certain things which happens occasionally, and we handle it in different way [not in regular way].

For example, a festival is an occasion, which is not like our regular day to office, and we have a different plan for that special day and that is called an Exception.

Somehow we have the perception that Exception means something wrong/unexpected happened but which is not the case always

Exception Handling In Real Life – Human eye:

When an object appears near to your eyes with considerable force, the eyelid close automatically i.e., the Eye Lid is there to protect your eye, as it expects these situations to occur and force an action.

Exception Handling in Java:

The answer is pretty simple, put a try/catch block around the code which you feel is expected to fail / might need a substitute action.

In the above human eye example, the eyelid act as the try/catch block around the eye, which reacts on the unexpected

Example 1a:  A service to withdraw amount from the given account

The above snippet is self-explanatory and you can notice that method has throws InSufficientBalanceException in its signature. 

InSufficientBalanceException is expected to be thrown by the service whenever the withdraw amount is greater than balance amt. So now the caller is forced to handle this exception.

Example 1b:  Exception handling

The above client code calls the service [line 5] in a try / catch block [Line 4 – 10], if you have sufficient fund then transaction happens and the doll is yours [line 6], else the exception will be thrown by the service and it is logged in the catch block [line 9] and corrective action should be taken accordingly here the user can purchase by cash [Line 9]

This is what in java world we call it as Checked Exception / Compile time Exception, there is also another important type of exception called Unchecked Exception / Runtime Exception

 

 

 

 

 

 

 

 

So what is Unchecked Exception / Runtime Exception?

• Is that it cannot/should not have corrective action? – Big NO
• Is that because it occurs at runtime? - All Exceptions are expected to occur at runtime even the checked exception/compile exception so this cannot be the reason.

From the above answers it means, an Unchecked Exception can occur at runtime and it can be rectified/substitute action can also be applied but then this can be achieved with checked exception itself so why does unchecked Exception still exist?

Real world Example – Mobile and its insurance

When we purchase a mobile, it doesn’t come up insurance its up to the owner to decide whether it has to be insured or not.

If something happens for the uninsured mobile, it becomes purely the owner’s risk.

Some users feel the insurance is not required for them because of its low price, or the insurance doesn’t cover all the disabilities.

Similarly in java programming, the caller will be given the rights to handle/not to handle the exception i.e., compiler will not force them to write the try/catch block

If you can revisit Example 1a, you can see that retrieveAvailableBalance() method is called to get the available balance, assume if the account does not exist/not active then the service has to let the caller know about it.

Example 2a: Runtime Exception

You can see that the method do not have throws in its signature, that means the compiler will not force the caller of this method to put try/catch block i.e, eventhough we introduced new exception [InvalidAccountException], Example 1a & 1b still will compile without any change and it will works fine for a valid account

Now, the question what happens to the client/caller [Example 1b] for invalid account?

Yes, it will fail abnormally as the caller didn’t had the try/catch/rethrow when he calls the service, so the client code [Example 1b] should be something like below:


Example 2b: Exception Handling

Now we have the exception handling for invalid account is also in place.

There are many other things in Exception, Hierarchies, Best Practices, etc that are not covered in this article as my primary focus is on Exception and not on the Exception API

I would recommend readers not to stop it here, there are many better-written articles available.

  

  

Below are some of the articles on Exception:

Anders Hejlsberg on checked vs. unchecked exceptions

http://www.artima.com/intv/handcuffs.html

James Gosling on checked exceptions

http://www.artima.com/intv/solid.html

Bill Venners on Exceptions

http://www.artima.com/interfacedesign/exceptions.html

Jacob Jenkov - Exception Handling

http://tutorials.jenkov.com/java-exception-handling/catching-multiple-exceptions.html

An Exceptional Philosophy:

http://www.dlugosz.com/Magazine/WTJ/May96/