What are JVM processes?

As we have established already in Chapter 1, Java Virtual Machine (JVM) on Your Computer, JVM does not know anything about the Java language and source code. It only knows how to read Byte Code. It reads the bytecodes and other information from .class files, interprets it (transforms it into the sequence of binary code instructions specific to a particular microprocessor, where JVM is running), and passes the result to the computer that executes it.

While talking about it, programmers often refer to JVM as JVM instance or process. This is because every time a java command is executed, a new instance of JVM is launched, dedicated to running the particular application in a separate process with the allocated memory size (default or passed in as the command option). Inside this JVM process, multiple threads are running, each with their own allocated memory; some are service threads created by the JVM, while others are application threads created and controlled by the application.

Threads are lightweight processes that require less resource allocation than the JVM execution process. 

That is the big picture of JVM executing the compiled code. But if you look closer and read the JVM Specification, you will discover that the word process in relation to JVM is overloaded many times. The JVM Specification identifies several other processes running inside the JVM that are usually not mentioned by programmers, except maybe the class loading process.

That is so because, most of the time, one can successfully write and execute Java programs without knowing more than that about JVM. But once in a while, some general understanding of JVM's internal workings helps to identify the root cause of certain related issues. That is why, in this section, we will provide a short overview of all the processes that happen inside JVM. Then, in the following sections, we will discuss JVM's memory structure and some other aspects of JVM functionality that may be useful to a programmer in more detail. 

There are two subsystems that run all the JVM internal processes:

• Classloader, which reads .class files and populates method areas in JVM memory with the class-related data:
  • Static fields
  • Method bytecodes
  • Class metadata that describes the class
• Execution engine, which executes the bytecodes using:
  • Heap area for object instantiation
  • Java and native method stacks for keeping track of the methods called
  • A garbage collection process to reclaim the memory

The list of the processes that run inside the main JVM process includes:

• Processes performed by the classloader:
  • Class loading
  • Class linking
  • Class initialization
• Processes performed by the execution engine:
  • Class instantiation
  • Method execution
  • Garbage collection
  • Application termination

The JVM architecture can be described as having two subsystems—the classloader and the execution engine—that run the service processes and application threads using runtime data memory areas: method area, heap, and application thread stacks.

The preceding list may give you the impression that these processes are executed sequentially. To some degree, this is true, if we talk about one class only. It is not possible to do anything with a class before loading. Аn execution of a method can begin only after all the previous processes are completed. However, the garbage collection, for example, doesn't happen immediately after the object stops being used (see the following section, Garbage collection). Also, an application can exit any time when an unhandled exception or some other error happens.

Only the classloader processes are regulated by the JVM specification. The execution engine's implementation is largely at the discretion of each vendor. It is based on the language semantics and the performance goals set by the implementation authors.  

The processes of the execution engine are not regulated by the JVM Specification. There is common sense, tradition, known and proven solutions, and the Java language specification that can guide a JVM vendor's implementation decisions, but there is no single regulatory document. The good news is that the most popular JVMs use similar solutions or, at least, that's how it looks from a high level of an introductory course. For vendor-specific details, see Comparison of Java virtual machines on Wikipedia (https://en.wikipedia.org/wiki/Comparison_of_Java_virtual_machines) and other sources available on the internet.

With this in mind, let's describe each of the seven processes listed previously in more detail.