Inside Java : The Java Virtual Machine

Posted on Jan 29, 2011 by celax

At the heart of the platform lies the Virtual Machine, or JVM. Most compile source code directly into machine code, suitable for execution on a particular microprocessor architecture. The difference with is that it uses bytecode – a special type of machine code.

bytecode executes on a special type of microprocessor. Strangely enough, there wasn’t a hardware implementation of this microprocessor available when was first released. Instead, the processor architecture is emulated by what is known as a “virtual machine”. This virtual machine is an emulation of a real processor – a machine within a machine (Figure One). The only difference is that the virtual machine isn’t running on a CPU – it is being emulated on the CPU of the host machine.

Java Virtual Machine

Figure One – JVM emulation run on a physical CPU

The Virtual Machine is responsible for interpreting bytecode, and translating this into actions or operating system calls. For example, a request to establish a socket connection to a remote machine will involve an operating system call. Different operating systems handle sockets in different ways – but the programmer doesn’t need to worry about such details. It is the responsibility of the JVM to handle these translations, so that the operating system and CPU architecture on which software is running is completely irrelevant to the developer.

Java Runtime Environment

Figure Two – JVM handles translations

The Virtual Machine forms part of a large system, the Runtime Environment (). Each operating system and CPU architecture requires a different . The comprises a set of base classes, which are an implementation of the base API, as well as a JVM. The portability of comes from implementations on a variety of CPUs and architectures. Without an available for a given environment, it is impossible to run software.

Differences between JVM implementations

Though implementations of Virtual Machines are designed to be compatible, no two JVMs are exactly alike. For example, garbage collection algorithms vary between one JVM and another, so it becomes impossible to know exactly when memory will be reclaimed. The thread scheduling algorithms are different between one JVM and another (based in part on the underlying operating system), so that it is impossible to accurately predict when one thread will be executed over another.

Initially, this is a cause for concern from programmers new to the language. However, it actually has very little practical bearing on development. Such predictions are often dangerous to make, as thread scheduling and memory usage will vary between different hardware environments anyway. The power of comes from not being specific about the operating system and CPU architecture – to do so reduces the portability of software.


The Virtual Machine provides a platform-independent way of executing code, by abstracting the differences between operating systems and CPU architectures. Runtime Environments are available for a wide variety of hardware and software combinations, making a very portable language. Programmers can concentrate on writing software, without having to be concerned with how or where it will run. The idea of virtual machines is nothing new, but is the most widely used virtual machine used today. Thanks to the JVM, the dream of Write Once-Run Anywhere (WORA) software has become a reality.

By David Reilly