JVM (Java Virtual Machine) is an abstract computing model. Just like a real machine, it has its own instruction set, execution engine, and serves to manipulate memory areas at run time. The objective is to provide an execution environment for applications built to run on it. JVM interprets the instruction code and interacts with the underlying layers: the OS platform and hardware architecture for execution of the instructions and resource management. This article gives an overview of the JVM and how a Java program executes within it.
Virtual machines are basically non-physical computers built to provide an environment that serves a specific or sometimes a general purpose. It sounds very similar to an Emulator that emulates a hardware component which either is not present in the machine or cannot perform as per requirement. So, what we do is create software that pretends that the specific hardware component is actually present in the system by providing the services provided by the actual hardware in the form of software. Virtual machines use CPU virtualization to am extent, providing an interface to the real hardware issues. So, in essence, both provide a virtual environment or an abstraction of something which it is not. However, differences between them obvious as we dive deeper. Let’s not focus on their differences for now. The point is that they pose something that they are not. In the words of Popek and Goldberg in the article ” Formal Requirements for Virtualizable Third Generation Architectures ,” it is “an efficient, isolated duplicate of the real machine. ”
Virtual Machines have types, induced by their needs and usages. One is called full virtualization, which behaves like a real machine. Others are a little subtler and more specific, like process virtualization. It is difficult to typify JVM to any particular genre because JVM virtualizes a CPU, has its own runtime environment and memory manager that work in collaboration with the underlying platform, garbage collector, and, of course, its band of class libraries infused as an intermediate bytecode and last, but not least, emulates machine registers, stacks, and so forth. In short, it is a playground of the essence of Java called bytecode transformed by the Java compiler. Bytecodes are practically machine code for the JVM which reinterprets them into native machine instructions.
Interestingly, JVM does not care about the Java language or any other programming language with respect to its semantics and syntactical structure. When it comes to executing a program, its primary interest lies in a particular file format called the class file format. The file format *.class has nothing to do with object-oriented class structure defined in Java code. It is a *.java file transformed into a *.class file by the compiler. JVM is ready to interpret class files; it does not matter what compiler is used create it as long as it creates a class file format. The Java compiler compiles a program into its equivalent class files. These class files actually contain half-compiled code called bytecode.
