Scribd
Upload
25 views6 pages

JDK, JRE, and JVM Overview

The document explains the Java Development Kit (JDK), Java Runtime Environment (JRE), and Java Virtual Machine (JVM), detailing their roles in Java application development and execution. JDK includes tools for development, while JRE is for running Java applications, and JVM serves as the runtime engine that executes Java bytecode. It also describes the workings of JDK, JRE, and JVM, including class loading, memory areas, and the execution engine.

Uploaded by

shravanmb163
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
25 views6 pages

JDK, JRE, and JVM Overview

The document explains the Java Development Kit (JDK), Java Runtime Environment (JRE), and Java Virtual Machine (JVM), detailing their roles in Java application development and execution. JDK includes tools for development, while JRE is for running Java applications, and JVM serves as the runtime engine that executes Java bytecode. It also describes the workings of JDK, JRE, and JVM, including class loading, memory areas, and the execution engine.

Uploaded by

shravanmb163
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Assignment 3: JDK, JRE And JVM

JDK

The Java Development Kit (JDK) is a cross-platformed software development environment that offers a
collection of tools and libraries necessary for developing Java-based software applications and applets. It is a
core package used in Java, along with the JVM and the JRE (Java Runtime Environment).

Beginners often get confused with JRE and JDK, if you are only interested in running Java programs on your
machine then you can easily do it using Java Runtime Environment. However, if you would like to develop a
Java-based software application then along with JRE you may need some additional necessary tools, which is
called JDK

he JDK has a private Java Virtual Machine (JVM) and a few other resources necessary for the development of
a Java Application.
JDK contains:
• Java Runtime Environment (JRE),
• An interpreter/loader (Java),
• A compiler (javac),
• An archiver (jar) and many more.

Working of JDK
The JDK enables the development and execution of Java programs. Consider the following process:
• Java Source File (e.g., [Link]): You write the Java program in a source file.

• Compilation: The source file is compiled by the Java Compiler (part of JDK) into bytecode,
which is stored in a .class file (e.g., [Link]).
• Execution: The bytecode is executed by the JVM (Java Virtual Machine), which interprets the
bytecode and runs the Java program

JRE – Java Runtime Environment

The JRE is an installation package that provides an environment to only run(not develop) the Java program
(or application) onto your machine. JRE is only used by those who only want to run Java programs that are
end-users of your system.

Working of JRE
When you run a Java program, the following steps occur:
• Class Loader: The JRE’s class loader loads the .class file containing the bytecode into memory.
• Bytecode Verifier: The bytecode verifier checks the bytecode for security and correctness.
• Interpreter: The JVM interprets the bytecode and executes the program.
• Execution: The program executes, making calls to the underlying hardware and system resources
as needed.
JVM – Java Virtual Machine

JVM(Java Virtual Machine) runs Java applications as a run-time engine. JVM is the one that calls
the main method present in a Java code. JVM is a part of JRE(Java Runtime Environment).
Java applications are called WORA (Write Once Run Anywhere). This means a programmer can develop Java
code on one system and expect it to run on any other Java-enabled system without any adjustment. This is all
possible because of JVM.
When we compile a .java file, .class files(contains byte-code) with the same class names present in .java file
are generated by the Java compiler. This .class file goes into various steps when we run it. These steps together
describe the whole JVM.

1. Class Loader Subsystem


The Class Loader Subsystem has three main tasks: loading, linking, and initialization.

Loading:
The class loader reads the ".class" file, generates binary data, and stores it in the method area. It saves details
like the class name, parent class, whether it's a class, interface, or enum, and information about methods and
variables. After loading, the JVM creates a Class object in the heap memory that represents this file. This Class
object can be used to get information about the class, such as its name, parent class, and methods, using the
getClass() method.

Linking:
This process involves verification, preparation, and resolution.
• Verification checks if the ".class" file is correctly formatted. If not, a runtime exception
([Link]) occurs.
• Preparation allocates memory for static variables and initializes them to default values.
• Resolution replaces symbolic references with direct references by searching the method area.

Initialization:
In this phase, static variables are assigned values defined in the code and static blocks, executed in order from
top to bottom.

There are three class loaders:

• Bootstrap Class Loader: Loads core Java API classes from the JAVA_HOME/lib directory. It is
implemented in native code.
• Extension Class Loader: Loads classes from the JAVA_HOME/jre/lib/ext directory or specified by
[Link]. It is implemented in Java.
• System/Application Class Loader: Loads classes from the application classpath defined by
[Link]. It is also implemented in Java.

2. Class Loaders
There are three main types of class loaders:

• Bootstrap Class Loader: Loads core Java API classes; not a Java object.
• Extension Class Loader: Loads classes from extension directories; implemented in Java.
• System/Application Class Loader: Loads classes from the application classpath; also implemented in
Java.

3. JVM Memory Areas


• Method Area: Stores class-level information, including class names and static variables.
• Heap Area: Stores all object information; there’s one heap area per JVM.
• Stack Area: Each thread has a runtime stack for method calls and local variables; it is not shared.
• PC Registers: Store the address of the current instruction for each thread; separate for each thread.
• Native Method Stacks: Each thread has a separate stack for native method information.

4. Execution Engine
The Execution Engine executes the ".class" (bytecode) by reading it line by line and using information from
memory areas. It consists of three parts:

• Interpreter: Interprets bytecode line by line, but can be slow for repeated method calls.
• Just-In-Time Compiler (JIT): Compiles bytecode into native code to improve efficiency for repeated
calls.
• Garbage Collector: Destroys unreferenced objects.

5. Java Native Interface (JNI)


JNI is an interface that allows interaction with native libraries (C, C++) for execution, enabling the JVM to call
and be called by C/C++ libraries.

6. Native Method Libraries


These are collections of native libraries needed for executing native methods, typically written in C and C++.
Language Used in Java Virtual Machine

Java Virtual Machine (JVM) is mainly written in C, C++, and Assembly, depending on the implementation,
with HotSpot JVM being the most widely used.

C and C++ provide low-level system access, which is crucial for memory management and performance
optimizations, offering faster execution than higher-level languages. Key JVM components like Garbage
Collection (GC), Thread Management, and Just-In-Time (JIT) Compilation require efficient low-level
programming.

Specific parts of the JVM written in C/C++ include the Class Loader Subsystem, Memory Management (Heap,
Stack, Method Area), Garbage Collector implementation, JIT Compiler, and Java Native Interface (JNI). The
HotSpot JVM’s memory allocation and garbage collection are implemented in C++ for enhanced performance.

Assembly language is used for platform-specific optimizations, enabling direct interaction with CPU registers
and efficient thread scheduling. Different OS and CPU architectures necessitate different Assembly instructions,
so JVM implementations use tailored assembly optimizations.

Parts of the JVM that utilize Assembly include Thread scheduling, efficient CPU instruction execution (JIT
compiler optimizations), and atomic operations for low-level memory handling. In HotSpot JVM, Assembly is
integral to JIT Compilation for generating optimized machine code across various CPU architectures.

Java itself is employed for the standard library and some JVM tools, as the Java Standard Library (JDK) is
predominantly written in Java. Components such as debugging tools and monitoring utilities are implemented in
Java.

Sections of the JVM written in Java encompass Standard Java APIs (Collections, Streams), JVM Management
Tools (JConsole, jstat, jmap), and the Java Class Library ([Link], [Link]).

Different JVM implementations mix C, C++, Assembly, and Java. HotSpot JVM primarily consists of C++,
some Assembly, and Java for libraries, while OpenJ9 JVM is largely in C and C++, with some Java. GraalVM
is mainly in Java and compiles Java to native code, and Dalvik/ART (Android JVMs) primarily employs C++
and some Assembly.

In summary, JVM mainly relies on C and C++ for core implementation (memory management, GC, JIT
Compiler, threading), uses Assembly for low-level CPU optimizations (thread scheduling, atomic operations),
and Java for standard libraries and JVM monitoring tools.

Common questions

Powered by AI

The class loader subsystem of the JVM plays a pivotal role in Java's platform independence by allowing dynamic loading, linking, and initialization of classes at runtime. It reads '.class' files, generates binary data, and stores it into the method area . The linking phase resolves symbolic references into direct references within the method area, ensuring compatibility with the underlying system without recompilation . By abstracting these processes and managing dependencies at runtime, the JVM allows Java applications to run on any device equipped with a compatible JVM, thus enabling Java's 'write once, run anywhere' capability .

The Just-In-Time (JIT) compiler within the JVM's execution engine enhances performance by translating Java bytecode into native machine code at runtime. This reduces the overhead associated with interpreting bytecode repeatedly for commonly used methods by optimizing their execution speed . The JIT compiler caches these compilations and applies optimizations like inlining and loop unrolling, effectively decreasing method call headers and boosting overall program efficiency .

Garbage collection in the JVM automatically identifies and disposes of objects that are no longer in use to reclaim memory for new object creation, thus preventing memory leaks. It runs transparently during program execution and is performed by several algorithms like generational collection and mark-and-sweep, which optimize for both short-lived and long-lived objects . By efficiently managing memory deallocation, garbage collection enhances application performance and stability by reducing the overhead associated with manual memory management and mitigating potential memory depletion issues .

The Java Native Interface (JNI) serves as a bridge between Java applications running on the JVM and native applications or libraries written in languages like C and C++. It enables Java code to call and be called by native applications, allowing Java-based systems to leverage existing native libraries for performance-intensive tasks or to interact with platform-specific features not directly accessible through Java . This interaction allows developers to augment Java applications with the speed and efficiency of native code execution while maintaining the cross-platform advantages of Java .

Writing the JVM in C, C++, and Assembly offers significant advantages such as efficient memory management and performance optimizations critical for tasks like garbage collection and JIT compilation, which demand low-level access and control . C and C++ allow for direct system-level manipulation, which enables faster execution speeds compared to higher-level languages . Assembly is crucial for platform-specific optimizations, allowing direct interaction with CPU registers and fine-grained control over thread scheduling, which are essential for maximizing performance across different architectures .

In JVM memory management, different memory areas serve specialized functions. The method area stores class metadata, including method data and runtime constant pool, shared among threads . The heap area, on the other hand, is used to allocate memory for all Java objects and is shared across threads, with garbage collection managing the deallocation of this space . Finally, the stack area is unique to each thread, holding frame data that includes local variables, partial results, and method invocation records, facilitating method execution and thread-specific data management . Proper management of these memory sections is critical for optimizing resource utilization and ensuring efficient execution of Java applications. .

Different JVM implementations are optimized for various performance and development needs by leveraging distinct programming languages and methodologies. HotSpot is primarily in C++ and uses JIT compilation extensively for runtime performance enhancements and memory optimization, making it suitable for general-purpose Java applications . OpenJ9 also uses C and C++ and is designed for low memory footprint, making it ideal for constrained environments or cloud applications. GraalVM, largely implemented in Java, compiles Java bytecode to native code ahead of time, offering superior startup times and peak performance for microservices and cloud-native applications . These design decisions reflect a balance between performance, footprint, and flexibility, allowing developers to choose the JVM implementation best tailored to their specific application requirements .

The JVM achieves platform independence through its ability to interpret Java bytecode, which is platform-independent, into native CPU instructions tailored to each operating system and hardware configuration. Although implemented in languages like C++ and Assembly to leverage platform-specific optimizations for performance, the JVM abstracts these details by providing a uniform environment for bytecode execution regardless of the underlying platform . This abstraction layer, combined with Just-In-Time (JIT) compilation and adaptive optimizations across different architectures, allows Java programs to run unmodified on any capable JVM, thereby preserving the 'Write Once, Run Anywhere' philosophy inherent to Java .

The Bootstrap Class Loader, which is implemented in native code, primarily loads core Java API classes from the JAVA_HOME/lib directory. It is responsible for loading classes essential to the Java environment, such as those in the java.lang package . Conversely, the System/Application Class Loader, which is implemented in Java, loads classes from the application classpath defined by java.class.path. It is capable of loading classes that the application defines or depends on, offering flexibility for user-defined classes or libraries . This hierarchical delegation model ensures that essential system classes are prioritized and securely loaded by the bootstrap loader, whereas application-specific classes are managed by the application class loader. This separation enhances security and prevents user classes from overriding core Java classes .

The JDK (Java Development Kit) is essential for developing Java applications and includes tools like the Java Compiler (javac), an interpreter/loader, and an archiver. It also contains a private JVM (Java Virtual Machine) and bundles the JRE (Java Runtime Environment) as well . The JRE, on the other hand, provides an environment specifically for running Java applications; it includes class loaders and an interpreter, but does not have the tools for developing applications . The JVM is part of the JRE and serves as the run-time engine executing Java bytecode, enabling Java's "write once, run anywhere" capability by acting as an abstraction layer between the bytecode and the system hardware .

You might also like