This is the continuation of my previous blog post. Last post I shared my chapter 2 notes and here we go with chapter 3.
This chapter provides an overview of the "Hotspot Java Virtual Machine" (VM) architecture and it's major component. There are three major components of the HotSpot VM.
1) VM Runtime
2) JIT Compiler
3) and A Memory Manager (Runtime)
HotSpot VM High Level Architecture
HotSpot VM has a JIT compiler, client or server, is pluggable, as is the choice of garbage collector: Serial GC, Throughput, Concurrent or G1. VM also has a runtime (HotSpot VM Runtime) which provides services and common APIs to the JIT compilers and garbage collector. Runtime also provides basic functionality to the VM such as a launcher, thread management, Java Native Interface and so on.
VM yields high scalability by generating dynamic optimization. In other words it makes optimization decisions while the Java application running and generates high performing native machine instruction targeted for the underlying system architecture.
32-bit VMs are limited to 4 GB memory. It is important to note that the actual Java heap space available for 32-bit VM may be further limited depending on the underlying OS. For instance Windows OS the maximum Java heap available to the VM is around 1.5 GB. For Linux OS it is around 2.5 to 3.0 GB. The actual maximums vary due to memory address space consumed by both a given Java application and JVM version.
64-bit VM allows these systems to utilize more memory. However, with 64-bit VMs come a performance penalty due to an increase in size of the internal HotSpot VM's representation of Java objects, called Ordinary Object Pointers (OOPS), which have an increase in the width from 32-bit to 64-bit.
Increase in width results in fewer OOPS being available on a CPU cache line. The decrease in CPU cache efficiency results in about 8% to 15 % performance degradation compare to 32-bit JVM. A new feature called compressed oops, which is enabled with the -XX:+UseCompressedOops VM command line option, can yield 32-bit JVM performance with the benefit of larger 64-bit Java Heaps. Java application realize better performance with a 64-bit VM using compressed oops than they achieve with 32-bit VM. Application executes faster with improved CPU cache utilization.
HotSport VM Runtime
VM Runtime encompasses many responsibilities, including parsing of command line arguments, VM life cycle, class loading, byte code interpreter, exception handling, synchronization, thread management etc.
a) Command Line Options
VM Runtime parses command line options and configures the HotSpot VM based on those options. There are 3 main categories of command line options.
1) Standard Options - These options are expected to be accepted by all JVM implementation and stable between releases.
2) Non-standard Options - These options are not required to be supported by all JVM and begin with a -X option.
3) Developer Options - It begins with -XX prefix.
b) VM Life Cycle
The HotSpot VM Runtime is responsible for launching and shutting-down the HotSpot VM. The component that starts the VM is called the "launcher" (java, javaw, javaws (java web start)). Below are the steps which launcher executes to start the VM.
1) Parse command line options, such as -client or -server, determines the JIT compiler to load.
2) Establish the Java Heap size and JIT Compiler Type.
3) Establish environment varibales such as LD_LIBRARY_PATH and CLASSPATH.
4) Look for MAIN-Class name from command line or from JAR's manifest file.
5) Create VM using the standard JNI method (JNI_CreateJavaVM).
6) Once the VM is created and initialized, the Java Main-class is loaded and launcher gets the Java main methods attributes from the java main-class.
7) Java main method is invoked in the VM using JNI method CallStaticVoidMethod passing it the marshaled arguments from command line.
Once the java program completes it's execution both method's and program's exit status must be passed back to their caller. The Java main method is detached from the VM using JNI's method DetachCurrentThread and thread count decrements so the JNI can safely invoke DestroyJavaVM method.
Sorry could not finish typing my notes.. There are few lot more important stuff which I would love to remember from this chapter. More to come soon.
Manisha
