Supercharge Your Applications with GraalVM E-Book

A B Vijay Kumar

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 336

Veröffentlichungsjahr: 2021

Beschreibung

GraalVM is a universal virtual machine that allows programmers to compile and run applications written in both JVM and non-JVM languages. It improves the performance and efficiency of applications, making it an ideal companion for cloud-native or microservices-based applications.
This book is a hands-on guide, with step-by-step instructions on how to work with GraalVM. Starting with a quick introduction to the GraalVM architecture and how things work under the hood, you'll discover the performance benefits of running your Java applications on GraalVM. You'll then learn how to create native images and understand how AOT (ahead-of-time) can improve application performance significantly. The book covers examples of building polyglot applications that will help you explore the interoperability between languages running on the same VM. You'll also see how you can use the Truffle framework to implement any language of your choice to run optimally on GraalVM.
By the end of this book, you'll not only have learned how GraalVM is beneficial in cloud-native and microservices development but also how to leverage its capabilities to create high-performing polyglot applications.

Leseprobe

Supercharge Your Applications with GraalVM

Hands-on examples to optimize and extend your code using GraalVM's high performance and polyglot capabilities

A B Vijay Kumar

BIRMINGHAM—MUMBAI

Supercharge Your Applications with GraalVM

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author(s), nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Lazar

Publishing Product Manager: Kushal Dave

Senior Editor: Rohit Singh

Content Development Editor: Kinnari Chohan

Technical Editor: Karan Solanki

Copy Editor: Safis Editing

Project Coordinator: Francy Puthiry

Proofreader: Safis Editing

Indexer: Vinayak Purushotham

Production Designer: Shankar Kalbhor

First published: May 2021

Production reference: 3230821

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80056-490-9

www.packt.com

To the memory of my father, Amba Prasad, and my mother, Vasantha, for all their sacrifice and upbringing. I miss you both, but I am sure you are always around me, guiding me.

To my wife, Geetha, for all her love, support, and encouragement. Without her, I wouldn't have come this far. And to my new love, Bozo, our puppy.

Contributors

About the author

A B Vijay Kumar is an "IBM Distinguished Engineer" and chief technology officer focused on hybrid cloud management and platform engineering. He is responsible for providing technology strategies for managing complex application portfolios on hybrid cloud platforms using emerging tools and technologies.

He is an IBM Master Inventor who has more than 31 patents issued and 30 pending in his name. He has more than 23 years' experience at IBM. He is recognized as a subject matter expert for his contribution to advanced mobility in automation and has led several implementations involving complex industry solutions. He specializes in mobile, cloud, container, automotive, sensor-based machine-to-machine, Internet of Things, and telematics technologies.

I wish to thank my family, especially my lovely brothers, Ram and Shyam, and my extended family – Saroja, Priya Shyam, Suresh, Priya Balu, Kuvalesh, Ritvik, Rijjul, Midhushi, and other family members, for all their support and encouragement.

I wish to thank my colleagues and friends, Jhilam B, Joyil J, Naveen E, Archan G, Amit D, Arun N, and Vasu R, who have provided critical feedback and helped me through the journey of writing this book.

Special thanks to Chris Seaton, from Shopify, for helping me understand some tough concepts, and debugging my issues. I would also like to thank IBM Corp and my management for encouraging me and allowing me to write this book.

Last but not least, thanks to the awesome Packt team – Kunal, Rohit, Kinnari, Prajakta, Kushal, Karan, and everybody else behind the scenes, for their awesome support, without which this book would never have materialized.

About the reviewer

Esteban Ginez, a seasoned developer, currently works at the intersection of cloud infrastructure, web services, and new compiler tooling.

During his tenure at Oracle, he spent his time improving how people use web services. During his time on the GraalVM team, he worked on features making Java and the JVM better suited to cloud workloads. In the past, Esteban has worked at a variety of tech companies, including Amazon and Zillow. In his spare time, Esteban enjoys contributing to open source projects. Originally from Quito, Ecuador, Esteban graduated from the University of Calgary with a degree in computer science.

Table of Contents

Preface

Section 1: The Evolution of JVM

Chapter 1: Evolution of Java Virtual Machine

Technical requirements

Introduction to GraalVM

Learning how JVM works

Understanding the JVM architecture

Class loader subsystem

Memory subsystem

JVM execution engine subsystem

Native subsystem

Summary

Questions

Further reading

Chapter 2: JIT, HotSpot, and GraalJIT

Technical requirements

Setup environment

Installing OpenJDK Java

Installing JITWatch

Taking a deep dive into HotSpot and the C2 JIT compiler

Code cache

Compiler threshold

On-stack replacement

Tiered compilation

Understanding the optimizations performed by JIT

Inlining

Monomorphic, bimorphic, and megamorphic dispatch

Dead code elimination

Loop optimization – Loop unrolling

Escape analysis

Deoptimization

Non-entrant code

Zombie code

Graal JIT and the JVM Compiler Interface (JVMCI)

Summary

Questions

Further reading

Section 2: Getting Up and Running with GraalVM – Architecture and Implementation

Chapter 3: GraalVM Architecture

Reviewing modern architectural requirements

Smaller footprint

Quicker bootstrap

Polyglot and interoperability

Learning what the GraalVM architecture is

Reviewing the GraalVM editions (Community and Enterprise)

Understanding the GraalVM architecture

JVM (HotSpot)

Java Virtual Machine Compiler Interface (JVMCI)

Graal compiler and tooling

Truffle

Sulong – LLVM

SubstrateVM (Graal AOT and native image)

An overview of GraalVM microservices architecture

Understanding how GraalVM addresses various non-functional aspects

Performance and scalability

Security

DevOps – continuous integration and delivery

Summary

Questions

Further reading

Chapter 4: Graal Just-In-Time Compiler

Technical requirements

Setting up the environment

Setting up Graal

Understanding the Graal JIT compiler

Graal compiler configuration

Graal JIT compilation pipeline and tiered optimization

Graal intermediate representation

Understanding Graal compiler optimizations

Speculative optimization

Partial escape analysis

Inter-procedural analysis and inlining

Debugging and monitoring applications

Seafoam

Visual Studio Code extension

GraalVM Dashboard

Command-line tools

Chrome debugger

Summary

Questions

Further reading

Chapter 5: Graal Ahead-of-Time Compiler and Native Image

Technical requirements

Building native images

Analyzing the native image with GraalVM Dashboard

Understanding the code size breakdown report

Heap size breakdown

Understanding PGO

Native image configuration

Hosted options and resource configurations

Generating Graal graphs for native images

Understanding how native images manage memory

The Serial garbage collector

The G1 Garbage Collector

Managing the heap size and generating heap dumps

Building static native images and native shared libraries

Debugging native images

Limitations of Graal AOT (Native Image)

GraalVM containers

Summary

Questions

Further reading

Section 3: Polyglot with Graal

Chapter 6: Truffle for Multi-language (Polyglot) support

Exploring the Truffle language implementation framework

Exploring the Truffle interpreter/compiler pipeline

Self-optimization and tree rewriting

Partial Evaluation

Learning Truffle DSL

Polymorphic inline caching

Understanding how Truffle supports interoperability

Frame management and local variables

Dynamic Object Model

Understanding Truffle instrumentation

Ahead-of-time compilation using Truffle

Optimizing Truffle interpreter performance with launcher options

SimpleLanguage and Simple Tool

Summary

Questions

Further reading

Chapter 7: GraalVM Polyglot – JavaScript and Node.js

Technical requirements

Understanding the JavaScript (including Node.js) Truffle interpreter

Verifying JavaScript, Node, and npm installation and versions

JavaScript interoperability

Polyglot native images

Bindings

Multithreading

Asynchronous programming – Promise and await

Summary

Questions

Further reading

Chapter 8: GraalVM Polyglot – Java on Truffle, Python, and R

Technical requirements

Understanding Espresso (Java on Truffle)

Why do we need Java on Java?

Installing and running Espresso

Exploring polyglot interoperability with Espresso

Exploring Espresso interoperability with other Truffle languages

Understanding GraalPython – the Python Truffle interpreter

Installing Graal Python

Understanding the graalpython compilation and interpreter pipeline

Exploring interoperability between Java and Python

Exploring interoperability between Python and other dynamic languages

Understanding FastR – the R Truffle interpreter

Installing and running R

Exploring the interoperability of R

Summary

Questions

Further reading

Chapter 9: GraalVM Polyglot – LLVM, Ruby, and WASM

Technical requirements

Understanding LLVM – the (Sulong) Truffle interface

Installing the LLVM toolchain

Exploring LLVM interoperability

Understanding the LLVM managed environment

Understanding TruffleRuby – the Ruby Truffle interpreter

Installing TruffleRuby

Understanding the TruffleRuby interpreter/compiler pipeline

Exploring Polyglot interoperability with TruffleRuby

Understanding GraalWasm – the WASM Truffle interpreter

Understanding GraalWasm architecture

Installing and running GraalWasm

Installing Emscripten (emcc)

Summary

Questions

Further reading

Section 4: Microservices with Graal

Chapter 10: Microservices Architecture with GraalVM

Technical requirements

Overview of microservices architecture

Building microservices architecture with GraalVM

Understanding GraalVM containers

Case study – online book library

Functional architecture

Deployment architecture

Exploring modern microservices frameworks

Building BookInfoService using Spring without GraalVM

Building BookInfoService with Micronaut

Building BookInfoService with Quarkus

Building a serverless BookInfoService using fn project

Summary

Questions

Further reading

Assessments

Other Books You May Enjoy

Preface

GraalVM is a universal virtual machine that allows programmers to embed, compile, interoperate, and run applications written in JVM languages such as Java, Kotlin, and Groovy; non-JVM languages such as JavaScript, Python, WebAssembly, Ruby, and R; and LLVM languages such as C and C++.

GraalVM provides the Graal just-in-time (JIT) compiler, an implementation of the Java Virtual Machine Compiler Interface (JVMCI), which is completely built on Java and uses Java JIT compiler (C2 compiler) optimization techniques as the baseline and builds on top of them. The Graal JIT compiler is much more sophisticated than the Java C2 JIT compiler. GraalVM is a drop-in replacement for the JDK, which means that all the applications that are currently running on the JDK should run on GraalVM without any application code changes.

GraalVM also provides ahead-of-time (AOT) compilation to build native images with static linking. GraalVM AOT compilation helps build native images that have a very small footprint and faster startup and execution, which is ideal for modern-day microservices architectures.

While GraalVM is built on Java, it not only supports Java, but also enables polyglot development with JavaScript, Python, R, Ruby, C, and C++. It provides an extensible framework called Truffle that allows any language to be built and run on the platform.

GraalVM is becoming the default runtime for running cloud-native Java microservices. Soon, all Java developers will be using GraalVM to run their cloud-native Java microservices. There are already a lot of microservices frameworks that are emerging in the market, such as Quarkus, Micronaut, Spring Native, and so on, that are built on GraalVM.

Developers working with Java will be able to put their knowledge to work with this practical guide to GraalVM and cloud-native microservice Java frameworks. The book provides a hands-on approach to implementation and associated methodologies that will have you up and running, and productive in no time. The book also provides step-by-step explanations of essential concepts with simple and easy-to-understand examples.

This book is a hands-on guide for developers who wish to optimize their apps' performance and are looking for solutions. We will start by giving a quick introduction to the GraalVM architecture and how things work under the hood. Developers will quickly move on to explore the performance benefits they can gain by running their Java applications on GraalVM. We'll learn how to create native images and understand how AOT can improve application performance significantly. We'll then move on to explore examples of building polyglot applications and explore the interoperability between languages running on the same VM. We'll explore the Truffle framework to implement our own languages to run optimally on GraalVM. Finally, we'll also learn how GraalVM is specifically beneficial in cloud-native and microservices development.

Who this book is for

The primary audience for this book is JVM developers looking to optimize their application's performance. This book would also be useful to JVM developers who are exploring options to develop polyglot applications by using tooling from the Python/R/Ruby/Node.js ecosystem. Since this book is for experienced developers/programmers, readers must be well-versed in software development concepts and should have good knowledge of working with programming languages.

What this book covers

Chapter 1, Evolution of Java Virtual Machine, walks through the evolution of JVM and how it optimized the interpreter and compiler. It will walk through C1 and C2 compilers, and the kind of code optimizations that JVM performs to run Java programs faster.

Chapter 2, JIT, HotSpot, and GraalJIT, takes a deep dive into how JIT compilers and Java HotSpot work and how JVM optimizes code at runtime.

Chapter 3, GraalVM Architecture, provides an architecture overview of Graal and the various architecture components. The chapter goes into details on how GraalVM works and how it provides a single VM for multiple language implementations. This chapter also covers the optimizations GraalVM brings on top of standard JVM.

Chapter 4, Graal Just-In-Time Compiler, talks about the JIT compilation option of GraalVM. It goes through the various optimizations the Graal JIT compiler performs in detail. This is followed by a hands-on tutorial to use various compiler options to optimize the execution.

Chapter 5, Graal Ahead-of-Time Compiler and Native Image, is a hands-on tutorial that walks through how to build native images and optimize and run these images with profile-guided optimization techniques.

Chapter 6, Truffle for Multi-language (Polyglot) support, introduces the Truffle polyglot interoperability capabilities and high-level framework components. It also covers how data can be transferred between applications that are written in different languages that are running on GraalVM.

Chapter 7, GraalVM Polyglot – JavaScript and Node.js, introduces the JavaScript and NodeJs. This is followed by a tutorial on how to use the Polyglot API for interoperability to interoperate between an example JavaScript and NodeJS application and a Python application.

Chapter 8, GraalVM Polyglot – Java on Truffle, Python, and R, introduces Python, R, and Java on Truffle (Espresso). This is followed by a tutorial on how to use the Polyglot API for interoperability between various languages.

Chapter 9, GraalVM Polyglot – LLVM, Ruby, and WASM, introduces JavaScript and Node.js. This is followed by a tutorial on how to use the Polyglot API to interoperate between an example JavaScript/Node.js applications.

Chapter 10, Microservices Architecture with GraalVM, covers the modern microservices architecture and how new frameworks such as Quarkus and Micronaut implement Graal for the most optimum microservices architecture.

To get the most out of this book

This book is a hands-on guide, with step-by-step instructions on how to work with GraalVM. Throughout the book, the author has used very simple, easy-to-understand code samples that will help you to understand the core concepts of GraalVM. All the code samples are provided in a Git repository. You are expected to have good knowledge of the Java programming language. The book also touches upon Python, JavaScript, Node.js, Ruby, and R – but the examples are intentionally kept simple, for understanding, while focusing on demonstrating the polyglot interoperability concepts.

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Supercharge-Your-Applications-with-GraalVM. In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Code in Action

Code in Action videos for this book can be viewed at https://bit.ly/3eM5ewO.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781800564909_ColorImages.pdf.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "In Truffle, it is a Java class derived from com.oracle.truffle.api.nodes.Node."

A block of code is set as follows:

@Fallback protected void typeError (Object left, Object right) {

    throw new TypeException("type error: args must be two         integers or floats or two", this);

}

Any command-line input or output is written as follows:

✗/Library/Java/JavaVirtualMachines/graalvm-ee-java11-21.0.0.2/Contents/Home/bin/npm --version

6.14.10

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Section 1: The Evolution of JVM

This section will walk through the evolution of JVM, and how it optimized the interpreter and compiler. It will walk through C1 and C2 compilers, and the kind of code optimizations that JVM performs to run Java programs faster.

This section comprises the following chapters:

Chapter 1, Evolution of Java Virtual MachineChapter 2, JIT, HotSpot, and GraalJIT

Chapter 1: Evolution of Java Virtual Machine

This chapter will walk you through the evolution of Java Virtual Machine (JVM), and how it optimized the interpreter and compiler. We will learn about C1 and C2 compilers and various types of code optimizations that the JVM performs to run Java programs faster.

In this chapter, we will cover the following topics:

Introduction to GraalVMLearning how JVM worksUnderstanding the JVM architectureUnderstanding the kind of optimizations JVM performs with Just-In-Time (JIT) compilersLearning the pros and cons of the JVM approach

By the end of this chapter, you will have a clear understanding of the JVM architecture. This is critical in understanding the GraalVM architecture and how GraalVM further optimizes and builds on top of JVM best practices.

Technical requirements

This chapter does not require any specific software/hardware.

Introduction to GraalVM

GraalVM is a high-performance VM that provides the runtime for modern cloud-native applications. Cloud-native applications are built based on the service architecture. The microservice architecture changes the paradigm of building micro applications, which challenges the fundamental way we build and run applications. The microservices runtimes demand a different set of requirements.

Here are some of the key requirements of a cloud-native application built on the microservice architecture:

Smaller footprint: Cloud-native applications run on the "pay for what we use" model. This means that the cloud-native runtimes need to have a smaller memory footprint and should run with the optimum CPU cycles. This will help run more workloads with fewer cloud resources.Quicker bootstrap: Scalability is one of the most important aspects of container-based microservices architecture. The faster the application's bootup, the faster it can scale the clusters. This is even more important for serverless architectures, where the code is initialized and run and then shut down on request.Polyglot and interoperability: Polyglot is the reality; each language has its strengths and will continue to. Cloud-native microservices are being built with different languages. It's very important to have an architecture that embraces the polyglot requirements and provides interoperability across languages. As we move to modern architectures, it's important to reuse as much code and logic as possible, that is time-tested and critical for business.

GraalVM provides a solution to all these requirements and provides a common platform to embed and run polyglot cloud-native applications. It is built on JVM and brings in further optimizations. Before understanding how GraalVM works, it's important to understand the internal workings of JVM.

Traditional JVM (before GraalVM) has evolved into the most mature runtime implementation. While it has some of the previously listed requirements, it is not built for cloud-native applications, and it comes with its baggage of monolith design principles. It is not an ideal runtime for cloud-native applications.

This chapter will walk you through in detail how JVM works and the key components of the JVM architecture.

Learning how JVM works

Java is one of the most successful and widely used languages. Java has been very successful because of its write once, run anywhere design principle. JVM realizes this design principle by sitting between the application code and the machine code and interpreting the application code to machine code.

Traditionally, there two ways of running application code:

Compilers: Application code is directly compiled to machine code (in C, C++). Compilers go through a build process of converting the application code to machine code. Compilers generate the most optimized code for a specific target architecture. The application code has to be compiled to target architectures. In general, the compiled code always runs faster than interpreted code, and issues with code semantics can be identified during compilation time rather than runtime.Interpreters: Application code is interpreted to machine code line by line (JavaScript and so on). Since interpreters run line by line, the code may not be optimized to the target architecture, and run slowly, compared to the compiled code. Interpreters have the flexibility of writing once and running anywhere. A good example is the JavaScript code that is predominantly used for web applications. This runs pretty much on different target browsers with minimal or no changes in the application code. Interpreters are generally slow and are good for running small applications.

JVM has taken the best of both interpreters and compilers. The following diagram illustrates how JVM runs the Java code using both the interpreter and compiler approaches:

Figure 1.1 – Java compiler and interpreter

Let's see how this works:

Java Compiler (javac) compiles the Java application source code to bytecode (intermediate format). JVM interprets the bytecode to machine code line by line at runtime. This helps in translating the optimized bytecode to target machine code, helping in running the same application code on different target machines, without re-programming or re-compiling.JVM also has a Just-In-Time (JIT) compiler to further optimize the code at runtime by profiling the code.

In this section, we looked at how Java Compiler and JIT work together to run Java code on JVM at a higher level. In the next section, we will learn about the architecture of JVM.

Understanding the JVM architecture

Over the years, JVM has evolved into the most mature VM runtime. It has a very structured and sophisticated implementation of a runtime. This is one of the reasons why GraalVM is built to utilize all the best features of the JVM and provide further optimizations required for the cloud-native world. To better appreciate the GraalVM architecture and optimizations that it brings on top of the JVM, it's important to understand the JVM architecture.

This section walks you through the JVM architecture in detail. The following diagram shows the high-level architecture of various subsystems in JVM:

Figure 1.2 – High-level architecture of JVM

The rest of this section will walk you through each of these subsystems in detail.

Class loader subsystem

The class loader subsystem is responsible for allocating all the relevant .class files and loading these classes to the memory. The class loader subsystem is also responsible for linking and verifying the schematics of the .class file before the classes are initialized and loaded to memory. The class loader subsystem has the following three key functionalities:

LoadingLinkingInitializing

The following diagram shows the various components of the class loader subsystem:

Figure 1.3 – Components of the class loader subsystem

Let's now look at what each of these components does.

Loading

In traditional compiler-based languages such as C/C++, the source code is compiled to object code, and then all the dependent object code is linked by a linker before the final executable is built. All this is part of the build process. Once the final executable is built, it is then loaded into the memory by the loader. Java works differently.

Java source code (.java) is compiled by Java Compiler (javac) to bytecode (.class) files. Class loader is one of the key subsystems of the JVM, which is responsible for loading all the dependent classes that are required to run the application. This includes the classes that are written by the application developer, the libraries, and the Java Software Development Kit (SDK) classes.

There are three types of class loaders as part of this system:

Bootstrap: Bootstrap is the first classloader that loads rt.jar, which contains all the Java Standard Edition JDK classes, such as java.lang, java.net, java.util, and java.io. Bootstrap is responsible for loading all the classes that are required to run any Java application. This is a core part of the JVM and is implemented in the native language.Extensions: Extension class loaders load all the extensions to the JDK found in the jre/lib/ext directory. Extension class loader classes are typically extension classes of the bootstrap implemented in Java. The extension class loader is implemented in Java (sun.misc.Launcher$ExtClassLoader.class).Application: The application class loader (also referred to as a system class loader) is a child class of the extension class loader. The application class loader is responsible for loading the application classes in the application class path (CLASSPATH env variable). This is also implemented in Java (sun.misc.Launcher$AppClassLoader.class).

Bootstrap, extension, and application class loaders are responsible for loading all the classes that are required to run the application. In the event where the class loaders do not find the required classes, ClassNotFoundException is thrown.

Class loaders implement the delegation hierarchy algorithm. The following diagram shows how the class loader implements the delegation hierarchy algorithm to load all the required classes:

Figure 1.4 – Class loader delegation hierarchy algorithm implementation flowchart

Let's understand how this algorithm works:

JVM looks for the class in the method area (this will be discussed in detail later in this section). If it does not find the class, it will ask the application class loader to load the class into memory.The application class loader delegates the call to the extension class loader, which in turn delegates to the bootstrap class loader.The bootstrap class loader looks for the class in the bootstrap CLASSPATH. If it finds the class, it will load to the memory. If it does not find the class, control is delegated to the extension class loader.The extension class loader will try to find the class in the extension CLASSPATH. If it finds the class, it will load to the memory. If it does not find the class, control is delegated to the application class loader.The application class loader will try to look for the class in CLASSPATH. If it does not find it, it will raise ClassNotFoundException, otherwise, the class is loaded into the method area, and the JVM will start using it.

Linking

Once the classes are loaded into the memory (into the method area, discussed further in the Memory subsystem section), the class loader subsystem will perform linking. The linking process consists of the following steps:

Verification: The loaded classes are verified for their adherence to the semantics of the language. The binary representation of the class that is loaded is parsed into the internal data structure, to ensure that the method runs properly. This might require the class loader to load recursively the hierarchy of inherited classes all the way to java.lang.Object. The verification phase validates and ensures that the methods run without any issues.Preparation: Once all the classes are loaded and verified, JVM allocates memory for class variables (static variables). This also includes calling static initializations (static blocks).Resolution: JVM then resolves by locating the classes, interfaces, fields, and methods referenced in the symbol table. The JVM might resolve the symbol during initial verification (static resolution) or may resolve when the class is being verified (lazy resolution).

The class loader subsystem raises various exceptions, including the following:

ClassNotFoundExceptionNoClassDefFoundErrorClassCastExceptionUnsatisfiedLinkErrorClassCircularityErrorClassFormatErrorExceptionInInitializerError

You can refer to the Java specifications for more details: https://docs.oracle.com/en/java/javase.

Initializing

Once all the classes are loaded and symbols are resolved, the initialization phase starts. During this phase, the classes are initialized (new). This includes initializing the static variables, executing static blocks, and invocating reflective methods (java.lang.reflect). This might also result in loading those classes.

Class loaders load all the classes into the memory before the application can run. Most of the time, the class loader has to load the full hierarchy of classes and dependent classes (though there is lazy resolution) to validate the schematics. This is time-consuming and also takes up a lot of memory footprint. It's even slower if the application uses reflection and the reflected classes need to be loaded.

After learning about the class loader subsystem, let's now understand how the memory subsystem works.

Memory subsystem

The memory subsystem is one of the most critical subsystems of the JVM. The memory subsystem, as the name suggests, is responsible for managing the allocated memory of method variables, heaps, stacks, and registers. The following diagram shows the architecture of the memory subsystem:

Figure 1.5 – Memory subsystem architecture

The memory subsystem has two areas: JVM level and thread level. Let's discuss each in detail.

JVM level

JVM-level memory, as the name suggests, is where the objects are stored at the JVM level. This is not thread-safe, as multiple threads might be accessing these objects. This explains why programmers are recommended to code thread-safe (synchronization) when they update the objects in this area. There are two areas of JVM-level memory:

Method: The method area is where all the class-level data is stored. This includes the class names, hierarchy, methods, variables, and static variables.Heap: The heap is where all the objects and the instance variables are stored.

Thread level

Thread-level memory is where all the thread-local objects are stored. This is accessible/visible to the respective threads, hence it is thread-safe. There are three areas of the thread-level memory:

Stack: For each method call, a stack frame is created, which stores all the method-level data. The stack frame consists of all the variables/objects that are created within the method scope, operand stack (used to perform intermediate operations), the frame data (which stores all the symbols corresponding to the method), and exception catch block information.Registers: PC registers keep track of the instruction execution and point to the current instruction that is being executed. This is maintained for each thread that is executing.Native Method Stack: The native method stack is a special type of stack that stores the native method information, which is useful when calling and executing the native methods.

Now that the classes are loaded into the memory, let's look at how the JVM execution engine works.

JVM execution engine subsystem

The JVM execution engine is the core of the JVM, where all the execution happens. This is where the bytecodes are interpreted and executed. The JVM execution engine uses the memory subsystem to store and retrieve the objects. There are three key components of the JVM execution engine, as shown:

Figure 1.6 – JVM execution engine architecture

We will talk about each component in detail in the following sections.

Bytecode interpreter

As mentioned earlier in this chapter, bytecode (.class) is the input to the JVM. The JVM bytecode interpreter picks each instruction from the .class file and converts it to machine code and executes it. The obvious disadvantage of interpreters is that they are not optimized. The instructions are executed in sequence, and even if the same method is called several times, it goes through each instruction, interprets it, and then executes.

JIT compiler

The JIT compiler saves the day by profiling the code that is being executed by interpreters, identifies areas where the code can be optimized and compiles them to target machine code, so that they can be executed faster. A combination of bytecode and compiled code snippets provide the optimum way to execute the class files.

The following diagram illustrates the detailed workings of JVM, along with the various types of JIT compilers that the JVM uses to optimize the code:

Figure 1.7 – The detailed working of JVM with JIT compilers

Let's understand the workings shown in the previous diagram:

The JVM interpreter steps through each bytecode and interprets it with machine code, using the bytecode to machine code mapping.JVM profiles the code consistently using a counter, to count the number of times a code is executed, and if the counter reaches a threshold, it uses the JIT compiler to compile that code for optimization and stores it in the code cache.JVM then checks whether that compilation unit (block) is already compiled. If JVM finds a compiled code in the code cache, it will use the compiled code for faster execution.JVM uses two types of compilers, the C1 compiler and the C2 compiler, to compile the code.

As illustrated in Figure 1.7, the JIT compiler brings in optimizations by profiling the code that is running and, over a period of time, it identifies the code that can be compiled. The JVM runs the compiled snippets of code instead of interpreting the code. It is a hybrid method of running interpreted code and compiled code.

JVM introduced two types of compilers, C1 (client) and C2 (server), and the recent versions of JVM use the best of both for optimizing and compiling the code at runtime. Let's understand these types better:

C1 compiler: A performance counter was introduced, which counted the number of times a particular method/snippet of code is executed. Once a method/code snippet is used a particular number of times (threshold), then that particular code snippet is compiled, optimized, and cached by the C1 compiler. The next time that code snippet is called, it directly executes the compiled machine instructions from the cache, rather than going through the interpreter. This brought in the first level of optimization.C2 compiler: While the code is getting executed, the JVM will perform runtime code profiling and come up with code paths and hotspots. It then runs the C2 compiler to further optimize the hot code paths. This is also known as a hotspot.

C1 is faster and good for short-running applications, while C2 is slower and heavy, but is ideal for long-running processes such as daemons and servers, so the code performs better over time.

In Java 6, there is a command-line option to use either C1 or C2 methods (with the command-line arguments -client (for C1) and -server (for C2)). In Java 7, there is a command-line option to use both. Since Java 8, both C1 and C2 compilers are used for optimization as the default behavior.

There are five tiers/levels of compilation. Compilation logs can be generated to understand which Java method is compiled using which compiler tier/level. The following are the five tiers/levels of compilation:

Interpreted code (level 0)Simple C1 compiled code (level 1)Limited C1 compiled code (level 2)Full C1 compiled code (level 3)C2 compiled code (level 4)

Let's now look at the various types of code optimizations that the JVM applies during compilation.

Code optimizations

The JIT compiler generates the internal representation of the code that is being compiled to understand the semantics and syntax. These internal representations are tree data structures, on which the JIT will then run the code optimization (as multiple threads, which can be controlled with the XcompilationThreads options from the command line).

The following are some of the optimizations that the JIT compilers perform on the code:

Inlining: One of the most common programming practices in object-oriented programming is to access the member variables through getter and setter methods. Inlining optimization replaces these getter/setter methods with actual variables. The JVM also profiles the code and identifies other small method calls that can be inlined to reduce the number of method calls. These are known as hot methods. A decision is taken based on the number of times that the method is called and the size of the method. The size threshold used by JVM to decide inlining can be modified using the -XX:MaxFreqInlineSize flag (by default, it is 325 bytes).Escape analysis: The JVM profiles the variables to analyze the scope of the usage of the variables. If the variables don't escape the local scope, it then performs local optimization. Lock Elision is one such optimization, where the JVM decided whether a synchronization lock is really required for the variable. Synchronization locks are very expensive to the processor. The JVM also decides to move the object from the heap to the stack. This has a positive impact on memory usage and garbage collection, as the objects are destroyed once the method is executed.DeOptimization: DeOptimization is another critical optimization technique. The JVM profiles the code after optimization and may decide to deoptimize the code. Deoptimizations will have a momentary impact on performance. The JIT compiler decides to deoptimize in two cases:

a. Not Entrant Code: This is very prominent in inherited classes or interface implementations. JIT may have optimized, assuming a particular class in the hierarchy, but over time when it learns otherwise, it will deoptimize and profile for further optimization of more specific class implementations.

b. Zombie Code: During Not Entrant code analysis, some of the objects get garbage collected, leading into code that may never be called. This code is marked as zombie code. This code is removed from the code cache.

Apart from this, the JIT compiler performs other optimizations, such as control flow optimization, which includes rearranging code paths to improve efficiency and native code generation to the target machine code for faster execution.

JIT compiler optimizations are performed over a period of time, and they are good for long-running processes. We will be going into a detailed explanation on JIT compilation in Chapter 2, JIT, Hotspot, and GraalVM.

Java ahead-of-time compilation

The ahead-of-time compilation option was introduced with Java 9 with jaotc, where a Java application code can be directly compiled to generate final machine code. The code is compiled to a target architecture, so it is not portable.

Java supports running both Java bytecode and AOT compiled code together in an x86 architecture. The following diagram illustrates how it works. This is the most optimum code that Java can generate:

Figure 1.8 – The detailed workings of JVM JIT time compilers along with the ahead-of-time compiler

The bytecode will go through the approach that was explained previously (C1, C2). jaotc compiles the most used java code (like libraries) into machine code, ahead of time, and this is directly loaded into the code cache. This will reduce the load on JVM. The Java byte code goes through the usual interpreter, and uses the code from the code cache, if available. This reduces a lot of load on JVM to compile the code at runtime. Typically, the most frequently used libraries can be AOT compiled for faster responses.

Garbage collector

One of the sophistication of Java is its in-built memory management. In languages such as C/C++, the programmer is expected to allocate and de-allocate the memory. In Java, JVM takes care of cleaning up the unreferenced objects and reclaims the memory. The garbage collector is a daemon thread that performs the cleanup either automatically or can also be invoked by the programmer (System.gc() and Runtime.getRuntime().gc()).

Native subsystem

Java allows programmers to access native libraries. Native libraries are typically those libraries that are built (using languages such as C/C++) and used for a specific target architecture. Java Native Interface (JNI) provides an abstraction layer and interface specification for implementing the bridge to access the native libraries. Each JVM implements JNI for the specific target system. Programmers can also use JNI to call the native methods. The following diagram illustrates the components of the native subsystem:

Figure 1.9 – Native subsystem architecture

The native subsystem