JVM Internals
JVM stands for Java Virtual Machine. Every Java application runs in its own JVM. It is an engine that runs java applications.
JVM is a part of JRE (Java Runtime environment). So on any machine where JRE is installed, we can run java applications.
The following shows the architecture diagram of the JVM :
JVM has the following areas :
1. ClassLoader subsystem
2. Runtime data area (memory area)
3. Execution engine
4. Native method interface
1. ClassLoader subsytem
Classloader is responsible for loading, linking and initialization of the classes.
a. Loading involves reading class files and store corresponding data in method area. For each class file, JVM stores fully qualified classname, fully qualified parent class name, constructor info, method info, variable info, constants info, modifiers info, etc.
After loading .class files, JVM immediately creates an object for that loaded class on the heap area of the type java. lang.Class. The Class class object can be used to get class-level information like constructors, methods, variables, etc. No matter how many objects of the class you create, all are the instances of the Class object. An example showing this can be found here
b. Linking consists of 3 activities : verification, preparation and resolution.
- Verification means checking the class file is generated by a valid compiler and is structurally correct. If its not, a verifyerror is thrown. Bytecode Verifier, a part of classloader subsystem, is responsible for this.
- Preparation involves allocation of memory to class-level static variables and default value assignments (original values will be assigned in next phase).
- Resolution involves replacing symbolic names with original memory references from method area.
c. Initialization involves assigning original values to class-level static variables and execution of static blocks.
If any error occurs in any of the above phases, we get runtime exception saying LinkageError.
Types of ClassLoaders :
1. Bootstrap ClassLoader :
- loads rt.jar which contains all the core java apis. it loads classes from bootstrap classpath. jre\lib
2. Extension ClassLoader :
- loads classes from extension classpath i.e. jre\lib\ext
3. Application/System ClassLoader :
- loads classes from application classpath i.e. the path we set as environment variable classpath or the classes within the path of the application.
Whenever a class is required, JVM asks the application classloader which in turn asks the extension classloader which asks the bootstrap classloader to load the class. If bootstrap unable then it asks extension to search, which if unable, returns back to app class loader and asks it to search. If found, class is loaded and if not, we get ClassNotFoundException or NoClassDefError.
Lets move to the memory areas in JVM.
Whenever JVM loads and runs a java program, it needs memory to store several things like bytecode, objects, variables, etc.
Total JVM memory organised into the following five categories :
1. Method area
- it is created at JVM startup. Inside method area, class-level binary data including static variables will be stored. Constant pools of a class will be stored inside method area. Method area data is not thread-safe.
2. Heap area
- it is created at JVM startup. Objects and instance variables are stored in heap area.
- We can find heap memory allocation using Runtime object provided by Java. An example can be found here. Try the example using java -Xmx512m -Xms64m {Classname}. It basically sets maximum and minimum heap memory.
3. Stack memory
For every thread, JVM creates a separate stack at the time of thread creation. Each and every method call performed by that thread is stored in the corresponding stack including local variables. After completing a method, the corresponding entry from the stack is removed. After all method execution is completed, the stack becomes empty and is destroyed by the JVM before thread termination.
Each entry in the stack is called stack frame. The data in the stack is only available to the corresponding threads. Hence it is thread-safe.
4. PC registers
5. Native method stacks
The above two memory parts are used by JVM itself.
The stack memory, PC registers and native method stack are present for every thread created by the JVM. While method area and heap area are one for the entire program.
JVM Execution Engine
Execution engine is responsible for execution of java classes.
It consists of two parts :
1. Interpreter
- As we know, java compiler generates bytecode. Interpreter reads this bytecode and interpret it into machine code and execute it line by line.
2. JIT compiler
- The issue with interpreter is that it intepretes even if same method is invoked again which results in low performance. To overcome this problem, JIT compiler was introduced. JIT compiles method into native code and if the same method is called again, JVM uses that native code directly and executes it directly rather than interpreting once again hence improvising the performance.
Apart from the above two parts, there are other parts in the engine such as profiler and garbage collector.
JNI is Java native method interface that provides information about native libraries to the JVM.
JVM is a part of JRE (Java Runtime environment). So on any machine where JRE is installed, we can run java applications.
The following shows the architecture diagram of the JVM :
JVM has the following areas :
1. ClassLoader subsystem
2. Runtime data area (memory area)
3. Execution engine
4. Native method interface
1. ClassLoader subsytem
Classloader is responsible for loading, linking and initialization of the classes.
a. Loading involves reading class files and store corresponding data in method area. For each class file, JVM stores fully qualified classname, fully qualified parent class name, constructor info, method info, variable info, constants info, modifiers info, etc.
After loading .class files, JVM immediately creates an object for that loaded class on the heap area of the type java. lang.Class. The Class class object can be used to get class-level information like constructors, methods, variables, etc. No matter how many objects of the class you create, all are the instances of the Class object. An example showing this can be found here
b. Linking consists of 3 activities : verification, preparation and resolution.
- Verification means checking the class file is generated by a valid compiler and is structurally correct. If its not, a verifyerror is thrown. Bytecode Verifier, a part of classloader subsystem, is responsible for this.
- Preparation involves allocation of memory to class-level static variables and default value assignments (original values will be assigned in next phase).
- Resolution involves replacing symbolic names with original memory references from method area.
c. Initialization involves assigning original values to class-level static variables and execution of static blocks.
If any error occurs in any of the above phases, we get runtime exception saying LinkageError.
Types of ClassLoaders :
1. Bootstrap ClassLoader :
- loads rt.jar which contains all the core java apis. it loads classes from bootstrap classpath. jre\lib
2. Extension ClassLoader :
- loads classes from extension classpath i.e. jre\lib\ext
3. Application/System ClassLoader :
- loads classes from application classpath i.e. the path we set as environment variable classpath or the classes within the path of the application.
Whenever a class is required, JVM asks the application classloader which in turn asks the extension classloader which asks the bootstrap classloader to load the class. If bootstrap unable then it asks extension to search, which if unable, returns back to app class loader and asks it to search. If found, class is loaded and if not, we get ClassNotFoundException or NoClassDefError.
Lets move to the memory areas in JVM.
Whenever JVM loads and runs a java program, it needs memory to store several things like bytecode, objects, variables, etc.
Total JVM memory organised into the following five categories :
1. Method area
- it is created at JVM startup. Inside method area, class-level binary data including static variables will be stored. Constant pools of a class will be stored inside method area. Method area data is not thread-safe.
2. Heap area
- it is created at JVM startup. Objects and instance variables are stored in heap area.
- We can find heap memory allocation using Runtime object provided by Java. An example can be found here. Try the example using java -Xmx512m -Xms64m {Classname}. It basically sets maximum and minimum heap memory.
3. Stack memory
For every thread, JVM creates a separate stack at the time of thread creation. Each and every method call performed by that thread is stored in the corresponding stack including local variables. After completing a method, the corresponding entry from the stack is removed. After all method execution is completed, the stack becomes empty and is destroyed by the JVM before thread termination.
Each entry in the stack is called stack frame. The data in the stack is only available to the corresponding threads. Hence it is thread-safe.
4. PC registers
5. Native method stacks
The above two memory parts are used by JVM itself.
The stack memory, PC registers and native method stack are present for every thread created by the JVM. While method area and heap area are one for the entire program.
JVM Execution Engine
Execution engine is responsible for execution of java classes.
It consists of two parts :
1. Interpreter
- As we know, java compiler generates bytecode. Interpreter reads this bytecode and interpret it into machine code and execute it line by line.
2. JIT compiler
- The issue with interpreter is that it intepretes even if same method is invoked again which results in low performance. To overcome this problem, JIT compiler was introduced. JIT compiles method into native code and if the same method is called again, JVM uses that native code directly and executes it directly rather than interpreting once again hence improvising the performance.
Apart from the above two parts, there are other parts in the engine such as profiler and garbage collector.
JNI is Java native method interface that provides information about native libraries to the JVM.
Comments
Post a Comment