JVM (Java Virtual Machine) Architecture – Part 2

In the previous article Part-1 (Please go through first this article), we start the discussion on JVM architecture. Until now we have done with part of the class loader subsystem. Now we moving further, anyone have doubts or suggestion. Please let me know through comments or mail.

Image is coming Soon

ClassLoader Working:

Classloader subsystem follows Delegation Hierarchy Principle. When a *.class is required then the first JVM will check the class in the method memory area. If JVM finds then use that *.class file.

If the class is not found in the method memory area, then JVM asks the class loader to load the required *.class file. Classloader subsystem request to Application class loader to load *.class file. Instead of searching in their application classpath, forward the request to Extension class loader to load required *.class file. Again, process repeats, Extension class loader forward the request to Bootstrap class loader.

Now, Bootstrap has the request for loading the requested *.class file. Bootstrap searches *.class file in bootstrap class path(JDK/JRE/lib/rt.jar). If finds then load the class file in the method memory area and if not then forward the requests back to the Extension classpath.  Extension class path searches *.class file in Extension classpath (JDK/JRE/lib/ext/*.jar). Again process repeats, If finds then loads the class file in method memory area and if not then forward the requests back to Application class loader to load *.class file.

Application class loader will search in the Application classpath. If it is available then it will be loaded otherwise we will get run time exception “NoClassDefFoundError” or “ClassNotFoundException”.

Note: After loading, linking is the second part of the class loader subsystem.

Linking: Three activities are come under linking part of the class loader subsystem. Three activities are: Verify, Prepare, Resolution.

  1. Verify: It is a verification process of byte-code (*.class file). Verify class files means ensuring the structurally correct of the binary representation of class files. JVM ensures class is built by an actual java compiler and properly formatted.
    JVM has a byte-code verifier responsible for this job. If any error occurs then we will get the run-time exception: java.lang.verifyError.
  2. Prepare: Prepare all the class level and interface level variables and assign the default values to them.
  3. Resolve: All the symbolic references (names) in our java code replaces with actual memory addresses from the method area.

Symbolic references are logical references, not actual references that locating physical memory location.

Initialization: In this, all class-level variables (static) types are assigned with their original values. Static blocks are executed at run time when classes are loaded or deployed on tomcat.

Note: If any error occurs in all three phases of the class loader subsystem then we get run-time exception java.lang.LinkageError.

Leave a Reply

Your email address will not be published. Required fields are marked *