JVM stands for Java Virtual Machine. As the name indicates, it is not a real machine; it is virtual or abstract which does not have a physical appearance. Like a physical machine converts one form into another, JVM also converts bytecode into binary code. Let us go further ih JVM Java Virtual Machine.
We know the Java compiler compiles the Java source file into a .class file containing bytecode. This bytecode is not understood by the microprocessor, in the sense, it is not in executable format (as processor understands only binary code). Java Virtual Machine (JVM) job is to interpret (convert) this bytecode into binary code format understood by the platform (operating system, on which this bytecode conversion takes place). This bytecode conversion is platform-dependent, that is, the same bytecode on another platform is converted into a different binary format understood (executed) by that platform. JVMs (implementations) for different platforms are different. The specific JVM is aware of the specific instruction set and other particulars of the platform. For this conversion, the execution of a Java program takes more time than C/C++. It may be around 20 times slower. It is brought down to around 10 times with the introduction of JIT compiler.
To give an example, the socket connections are low-level programming and require a method call which platform-dependent. A workstation may connect to different remote machines with different platforms. The JVM translates the bytecode into such a format that two systems with different platforms may communicate.
JIT (Just-In-Time) Compiler
The JIT compiler works at execution time (and not at compile time, as the name misleads). Earlier to JIT compiler, if the same method is called 10 times, all the 10 times the bytecode of the method is converted into binary code. The JIT compiler does the conversion only once and preserves this binary code. When the method is called again the same preserved binary code is called.
Java Runtime Environment (JRE)
The JVM put together with standard libraries (Java API) and Java Class Library is known as JRE.
JRE = JVM + Standard Libraries
HotSpot
Some languages source code (like Ada) can be converted into bytecode and this bytecode can be executed by JVM. Many languages like Ada and Scala etc. can run on the top of JVM.
Oracle Corporation, now who owns the Java trademark, developed the JVM and named it as HotSpot. HotSpot is written in C++ lang. Like a microprocessor, the JVM also comes with a stack based architecture.
Bytecode Verifier
The JVM is so designed that it does not crash the host operating system due to problems of bytecode instruction set execution. Also takes care of (does not allow to happen) the general programming problems like reading the array beyond its elements and uninitialized pointers etc. This is taken care by many features of Java like automatic garbage collector, class model and bytecode verifier.
Generally, a beginner thinks a bytecode verifies (or checks) the bytecode is in order or not. It is a wrong understanding of bytecode verifier. The bytecode verification before execution comes in three types of checking.
- Checks the accessibility of private (also with package protection) variables and methods. Strictly controls other classes cannot access these private members.
- As the Java does not support garbage values, verifier assures data is initialized and references are type-safe.
- Classes are loaded from valid locations.
The 2nd and 3rd checks are carried at class loading time and before execution. The 1st one checks at runtime with access specifiers between the classes of different packages. Memory protection is attained by not allowing the bit patterns to be made use of as addresses.
The bytecode instructions include type conversions, operand stack management and exceptions throwing etc.
JVM Heap
The memory area used by the JVM (HotSpot) is known as JVM heap. The JVM heap is divided into known as generations.
- Young generation: It stores the objects with short life; which are created and garbage collected immediately.
- Old (or Tenured) generation: It stores objects with long life; created and almost used by much of the code.
The PremGen (Permanent Generation) was introduced in the later part of JVM development to store classes with their related data (say, metadata). Before PermGen, the classes were also stored in the same objects area. Because class unloading occurs very rarely (that too once) and moving classes to PermGen increases the performance of JVM.
Secure Execution (for applets)
Everyone knows Java Applets are untrusted. Here untrusted means the applets being downloaded onto our machine may contain malicious code (that may damage the file system) as they were developed by unknown people and placed on unknown Web servers. JVM built-in the browser does not allow the applet to cross the boundaries of the browser’s execution context (does not allow accessing other parts of the OS).
Primordial Class Loader
The class loader job is to load the class for execution by JVM. Class loader is part of JVM and the built-in class loader of JVM is called as "Primordial class loader". A non-primordial class loader (simply called as class loader) is that one which a programmer can create himself and use in place of primordial. A class loader while loading the main() method class, also should load the referenced classes in the code like System and String etc.
The loading process is platform-dependent. When file is asked to load (with java command like "java Demo"), first the loader should search the OS file system to find the file to be loaded. File systems are platform dependent. Loader uses java.lang.ClassLoader class to load.
It requires a lot of intelligence in the design which is unparalled even today after the Java release of 1995. No company developed such a JVM so far. It stands as one of the unique features of Java.
Pass your comments and suggestions on this tutorial JVM Java Virtual Machine.
