0% found this document useful (0 votes)
84 views

The Java Virtual Machine "JVM": Prepared By: Alaa Aldeen Nofal Alano911@yahoo - Co.uk Al-Balqa Applied University

The document discusses the Java Virtual Machine (JVM). It begins by explaining that the JVM is a virtualized environment that allows Java applications to run the same across different physical environments. It then discusses the abstract specification of the JVM, concrete implementations of the JVM, and instances of the JVM at runtime. The document also examines the lifetime of a JVM instance and the internal architecture of the JVM as defined by its specification.

Uploaded by

Alaa Nofal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
84 views

The Java Virtual Machine "JVM": Prepared By: Alaa Aldeen Nofal Alano911@yahoo - Co.uk Al-Balqa Applied University

The document discusses the Java Virtual Machine (JVM). It begins by explaining that the JVM is a virtualized environment that allows Java applications to run the same across different physical environments. It then discusses the abstract specification of the JVM, concrete implementations of the JVM, and instances of the JVM at runtime. The document also examines the lifetime of a JVM instance and the internal architecture of the JVM as defined by its specification.

Uploaded by

Alaa Nofal
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 10

The Java Virtual Machine

“JVM”

Prepared By: Alaa Aldeen Nofal

[email protected]

Al-Balqa Applied University

Abstract
A virtual machine (VM) idea is one of the most elegant in the history of technology and is an advanced
step in the evolution of ideas about software. It’s an environment which does not physically exist but is
created within another environment and it’s referred to as virtualization. In this paper the main types of
Virtual machines will be introduce briefly, and then the Java Virtual Machine or JVM will be discussed
by discussing the abstract computer that runs compiled Java programs and see how these programs
are implemented in software on top of a "real" hardware platform and operating system and discuss
how JVM supports the JAVA portability.

Introduction
A virtual machine system is divided into two parts, the first one is a virtual machine (VM) itself and its
called a "guest" and the second part is the environment it runs within and it’s called a "host." It allows
the user to run multiple operating systems at the same time on single computer , since one host
environment can often run multiple VMs at once computer and each of them is separated from the
physical resources they use, the host environment is often able to dynamically assign those resources
among them, the user has a seemingly private machine with fully functional hardware that is separate
from other users, and each user can boot and restart his machines separately and quickly since tasks
such as hardware initialization are not necessary. This type of VMs is called hardware virtual machine
software, hypervisor. VM is useful when the user needs to execute an instruction set different than
that of the host environment. VM may also be a group of computers that work together to create a
more powerful machine using software that makes it possible for one environment to be formed
throughout several computers. So that the end user feels that he is using a single computer, although
there are actually a multiple computers works together. VM may also be a virtual environment,
a virtual private server and this is used for running programs at the user level. Another type of virtual
machines can refer to application software of which the application is isolated from the computer
being used because it's intended to be used on deferent computer platforms, So we will not need to
create separate versions of the same software for different operating systems and computers. A very
well known example of an application virtual machine is Java Virtual Machine JVM, and it would be
the main topic to be discussed in the later sections.
Java Virtual Machine JVM
JVM stands for "Java Virtual Machine". It's a virtualized environment that provides Java applications
with a way of running in the same way across multiple different physical environments. The idea is
that Java code is compiled and is executed by the JVM. The JVM provides the same look and feel for
the actual code regardless of whether it's being run on a massively parallel mainframe or a single
processor PC running Windows. These days the JVM is being used for languages other than Java
language. (Scala, for example).

To understand the Java virtual machine you must first be aware that you may be talking about any of
three different things when you say "Java virtual machine." You may be speaking of:
- the abstract specification,
- a concrete implementation, or
- a runtime instance.
To implement the JVM correctly, you need only be able to read the class file format and correctly
perform the operations specified therein.

Implementation details that are not part of the Java virtual machine’s specification would
unnecessarily constrain the creativity of implementers. For example, the memory layout of runtime
data areas, the garbage-collection algorithm used, and any internal optimization of the Java virtual
machine instructions (for example, translating them into machine code) are left to the discretion of the
implementer.

The Lifetime of a Java Virtual Machine


A runtime instance of the Java virtual machine has a clear mission in life: to run one Java application.
When a Java application starts, a runtime instance is born. When the application completes, the
instance dies. If you start three Java applications at the same time, on the same computer, using the
same concrete implementation, you'll get three Java virtual machine instances. Each Java application
runs inside its own Java virtual machine. (1)

A Java virtual machine instance starts running its solitary application by invoking the main() method of
some initial class. The main() method must be public, static, return void, and accept one parameter: a
String array. Any class with such a main() method can be used as the starting point for a Java
application.

For example, consider an application that prints out its command line arguments:

class Echo {

public static void main(String[] args) {


int le = args.length;
for (int j = 0; j < le; ++j) {
System.out.print(args[j] + " ");
}
System.out.println();
}}

‫ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

(1) Dening the Java Virtual Machine as Platformfor Provably Correct Java Compilation Egon B¨orger1 and
Wolfram Schulte21 Universit_a di Pisa, Dipartimento di Informatica, I-56125 Pisa.
You must in some implementation-dependent way give a Java virtual machine the name of the initial
class that has the main() method that will start the entire application. One real world example of a
Java virtual machine implementation is the java program from Sun's Java 2 SDK. If you wanted to run
the Echo application using Sun's java on Window98, for example, you would type in a command such
as: java Echo Greetings, Planet.(2)

The first word in the command, "java," indicates that the Java virtual machine from Sun's Java 2 SDK
should be run by the operating system. The second word, "Echo," is the name of the initial class.
Echo must have a public static method named main() that returns void and takes a String array as its
only parameter. The subsequent words, "Greetings, Planet.," are the command line arguments for the
application. These are passed to the main() method in the String array in the order in which they
appear on the command line. So, for the previous example, the contents of the String array passed to
main in Echo are: arg[0] is "Greetings," arg[1] is "Planet."

The main() method of an application's initial class serves as the starting point for that application's
initial thread. The initial thread can in turn fire off other threads.

Inside the Java virtual machine, threads come in two flavors: daemon and non- daemon. A daemon
thread is ordinarily a thread used by the virtual machine itself, such as a thread that performs garbage
collection. The application, however, can mark any threads it creates as daemon threads. The initial
thread of an application--the one that begins at main()--is a non- daemon thread. (2)

A Java application continues to execute (the virtual machine instance continues to live) as long as any
non-daemon threads are still running. When all non-daemon threads of a Java application terminate,
the virtual machine instance will exit. If permitted by the security manager, the application can also
cause its own demise by invoking the exit() method of class Runtime or System.

In the Echo application previous, the main() method doesn't invoke any other threads. After it prints
out the command line arguments, main() returns. This terminates the application's only non-daemon
thread, which causes the virtual machine instance to exit.

‫ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

(2) Dening the Java Virtual Machine as Platformfor Provably Correct Java Compilation Egon B¨orger1 and
Wolfram Schulte21 Universit_a di Pisa, Dipartimento di Informatica, I-56125 Pisa, Italy
[email protected] Universit¨at Ulm, Fakult¨at f¨ur Informatik, D-89069 Ulm, Germany [email protected]
ulm.de
The Architecture of the Java Virtual Machine
In the Java virtual machine specification, the behavior of a virtual machine instance is described in
terms of subsystems, memory areas, data types, and instructions. These components describe an
abstract inner architecture for the abstract Java virtual machine. The purpose of these components is
not so much to dictate an inner architecture for implementations. It is more to provide a way to strictly
define the external behavior of implementations. The specification defines the required behavior of
any Java virtual machine implementation in terms of these abstract components and their interactions.
Figure 1-1 shows a block diagram of the Java virtual machine that includes the major subsystems and
memory areas described in the specification. Each Java virtual machine has a class loader
subsystem: a mechanism for loading types (classes and interfaces) given fully qualified names. Each
Java virtual machine also has an execution engine: a mechanism responsible for executing the
instructions contained in the methods of loaded classes. (1)

Figure1-1. The internal architecture of the Java virtual machine.

When a Java virtual machine runs a program, it needs memory to store many things, including
bytecodes and other information it extracts from loaded class files, objects the program instantiates,
parameters to methods, return values, local variables, and intermediate results of computations. The
Java virtual machine organizes the memory it needs to execute a program into several runtime data
areas. (1)

Although the same runtime data areas exist in some form in every Java virtual machine
implementation, their specification is quite abstract. Many decisions about the structural details of the
runtime data areas are left to the designers of individual implementations.

Different implementations of the virtual machine can have very different memory constraints. Some
implementations may have a lot of memory in which to work, others may have very little. Some
implementations may be able to take advantage of virtual memory, others may not. The abstract
nature of the specification of the runtime data areas helps make it easier to implement the Java virtual
machine on a wide variety of computers and devices. (2)

‫ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

(1) Parameter Passing for the Java Virtual Machine K John Gough,Queensland University of
Technology, [email protected], page (2)
(2) Implementing a JavaTM Virtual Machine in the Java Programming Language
Antero Taivalsaari, SMLI TR-98-64 March 1998
Some runtime data areas are shared among all of an application's threads and others are unique to
individual threads. Each instance of the Java virtual machine has one method area and one heap.
These areas are shared by all threads running inside the virtual machine. When the virtual machine
loads a class file, it parses information about a type from the binary data contained in the class file. It
places this type information into the method area. As the program runs, the virtual machine places all
objects the program instantiates onto the heap. See Figure 1-2 for a graphical depiction of these
memory areas.

Figure 1-2. Runtime data areas shared among all threads.

As each new thread comes into existence, it gets its own pc register (program counter) and Java
stack. If the thread is executing a Java method (not a native method), the value of the pc register
indicates the next instruction to execute. A thread's Java stack stores the state of Java (not native)
method invocations for the thread.

The state of a Java method invocation includes its local variables, the parameters with which it was
invoked, its return value (if any), and intermediate calculations. The state of native method invocations
is stored in an implementation-dependent way in native method stacks, as well as possibly in registers
or other implementation-dependent memory areas. The Java stack is composed of stack frames (or
frames). A stack frame contains the state of one Java method invocation. When a thread invokes a
method, the Java virtual machine pushes a new frame onto that thread's Java stack. When the
method completes, the virtual machine pops and discards the frame for that method. (1)

The Java virtual machine has no registers to hold intermediate data values. The instruction set uses
the Java stack for storage of intermediate data values. This approach was taken by Java's designers
to keep the Java virtual machine's instruction set compact and to facilitate implementation on
architectures with few or irregular general purpose registers. In addition, the stack-based architecture
of the Java virtual machine's instruction set facilitates the code optimization work done by just-in-time
and dynamic compilers that operate at run-time in some virtual machine implementations. (2)

‫ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

(1) ³Proceedings of the, 2nd JavaTM Virtual Machine ,Research and Technology Symposium
(JVM '02), San Francisco, California, USA, August 1-2, 2002 ,THE ADVANCED
Data types of the Java virtual machine
Like the Java programming language, the Java virtual machine operates on two kinds of types:

- Primitive types
- Reference types.

There are, correspondingly, two kinds of values that can be stored in variables, passed as
arguments, returned by methods, and operated upon: primitive values and reference values.

Although boolean qualifies as a primitive type of the Java virtual machine, the instruction set has very
limited support for it. When a compiler translates Java source code into bytecodes, it uses ints or
bytes to represent booleans. In the Java virtual machine, false is represented by integer zero and true
by any non-zero integer. Operations involving boolean values use ints. Arrays of boolean are
accessed as arrays of byte, though they may be represented on the heap as arrays of byte or as bit
fields. (1)

The primitive types of the Java programming language other than boolean form the numeric types of
the Java virtual machine. The numeric types are divided between the integral types: byte, short, int,
long, and char, and the floating- point types: float and double. As with the Java programming
language, the primitive types of the Java virtual machine have the same range everywhere. A long in
the Java virtual machine always acts like a 64-bit signed twos complement number, independent of
the underlying host platform. (1)

The Java virtual machine works with one other primitive type that is unavailable to the Java
programmer: the returnAddress type. This primitive type is used to implement finally clauses of Java
programs.(1)

The reference type of the Java virtual machine is cleverly named reference. Values of type reference
come in three flavors: the class type, the interface type, and the array type. All three types have
values that are references to dynamically created objects. The class type's values are references to
class instances. The array type's values are references to arrays, which are full-fledged objects in the
Java virtual machine. The interface type's values are references to class instances that implement an
interface. One other reference value is the null value, which indicates the reference variable doesn't
refer to any object.(1)

The Java virtual machine specification defines the range of values for each of the data types, but does
not define their sizes.

‫ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

(1) THE STRUCTURE OF THE JAVA VIRTUAL MACHINE,page 61,62,63.64,65


The number of bits used to store each data type value is a decision of the designers of individual
implementations. The ranges of the Java virtual machines data type's are shown in Table 1-1.

Table 1-1. Ranges of the Java virtual machine's data types

The Class Loader Subsystem

The part of a Java virtual machine implementation that takes care of finding and loading types is the
class loader subsystem.

The Java virtual machine contains two kinds of class loaders: a bootstrap class loader and user-defined
class loaders. The bootstrap class loader is a part of the virtual machine implementation, and user-
defined class loaders are part of the running Java application. Classes loaded by different class
loaders are placed into separate name spaces inside the Java virtual machine. (1)

The class loader subsystem involves many other parts of the Java virtual machine and several
classes from the java.lang library. For example, user-defined class loaders are regular Java objects
whose class descends from java.lang.ClassLoader. The methods of class ClassLoader allow Java
applications to access the virtual machine's class loading machinery. Also, for every type a Java
virtual machine loads, it creates an instance of class java.lang.Class to represent that type. Like all
objects, user-defined class loaders and instances of class Class reside on the heap. Data for loaded
types resides in the method area. (2)

The Bootstrap Class Loader

Java virtual machine implementations must be able to recognize and load classes and interfaces
stored in binary files that conform to the Java class file format. An implementation is free to recognize
other binary forms besides class files, but it must recognize class files.

‫ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬

INSIDE THE JAVA VIRTUAL MACHINE, Filip Hanik, Covalent Technologies (1)
.August 29, 2007
(2) DynamicClass Loading in the JavaTM VirtualMachine Sheng Liang Gilad Bracha
.SunMicrosystems Inc
Every Java virtual machine implementation has a bootstrap class loader, which knows how to load
trusted classes, including the classes of the Java API. The Java virtual machine specification doesn't
define how the bootstrap loader should locate classes. That is another decision the specification
.leaves to implementation designers

Given a fully qualified type name, the bootstrap class loader must in some way attempt to produce the
data that defines the type. One common approach is demonstrated by the Java virtual machine
implementation in Sun's 1.1 JDK on Windows98. This implementation searches a user-defined
directory path stored in an environment variable named CLASSPATH. The bootstrap loader looks in
each directory, in the order the directories appear in the CLASSPATH, until it finds a file with the
appropriate name: the type's simple name plus ".class". Unless the type is part of the unnamed
package, the bootstrap loader expects the file to be in a subdirectory of one the directories in the
CLASSPATH. The path name of the subdirectory is built from the package name of the type. For
example, if the bootstrap class loader is searching for class java.lang.Object, it will look for
Object.class in the java\lang subdirectory of each CLASSPATH directory.

Conclusion

A JVM can also implement programming languages other than Java. For example, Ad a source code
can be compiled to Java bytecode, which may then be executed by a JVM. JVMs can also be
released by other companies besides Sun (the developer of Java).
JVMs using the "Java" trademark may be developed by other companies as long as they adhere to
the JVM specification published by Sun and to related contractual obligations.(1)

Java was conceived with the concept of WORA: "write once, run anywhere ". This is done using the
Java Virtual Machine. The JVM is the environment in which java programs execute. It is software that
is implemented on non-virtual hardware and on standard operating systems. (1)

JVM is a crucial component of the Java platform, and because JVMs are available for many hardware
and software platforms, Java can be both middleware and a platform in its own right. The use of the
same bytecode for all platforms allows Java to be described as "compile once, run anywhere", as
opposed to "write once, compile anywhere", which describes cross-platform compiled languages A
JVM also enables such features as automated exception handling , which provides "root-cause"
debugging information for every software error ( exception ), independent of the source code.
A JVM is distributed along with a set of standard class libraries that implement the Java application
programming interface (API). Appropriate APIs bundled together form the Java Runtime Environment
(JRE). (1)

Execution environment Programs intended to run on a JVM must be compiled into a standardized
portable binary format, which typically comes in the form of “class files”, A program may consist of
many classes in different files. For easier distribution of large programs, multiple class files may be
packaged together in a .jar file (short for Java archive). The JVM runtime executes .class or .jar files,
emulating the JVM instruction set by interpreting it, or using a just-in-time compiler (JIT) such as Sun's
HotSpot. JIT compiling, not interpreting, is used in most JVMs today to achieve greater speed. (2)

There are also ahead-of-time compilers that enable developers to pre-compile class files into native
code for particular platforms.

However, the JVM also has low-level support for Java-like classes and methods, which amounts to a
highly idiosyncratic, memory model and capability-based architecture.

The JVM, which is the instance of the 'JRE' (Java Runtime Environment), comes into action when a
Java program is executed. When execution is complete, this instance is garbage collected. JIT is the
part of the JVM that is used to speed up the execution time. JIT compiles parts of the bytecode that
have similar functionality at the same time, and hence reduces the amount of time needed for
compiling.

The JVM verifies all bytecode before it is executed. This verification consists primarily of three types
of checks:

- Branches are always to valid locations.


- Data is always initialized and references are always type-safe.
- Access to "private" or "package private" data and methods is rigidly controlled.
The first two of these checks take place primarily during the "verification" step that occurs when a
class is loaded and made eligible for use. The third is primarily performed dynamically, when data
items or methods of a class are first accessed by another class. (2)

‫ــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ‬
(1) Introduction to java Sang Shin ,Michèle Garoche, www.javapassion.com , “Learn with
Passion!”
(2) Speculative Multithreading in a Java Virtual Machine , Sable Technical Report No.
2005-1
Christopher J.F. Pickett and Clark Verbrugge

References

1. Dening the Java Virtual Machine as Platformfor Provably Correct Java Compilation Egon
B¨orger1 and Wolfram Schulte21 Universit_a di Pisa, Dipartimento di Informatica, I-56125 Pisa.
2. Parameter Passing for the Java Virtual Machine K John Gough,Queensland
University of Technology, [email protected], page (2)
3. Implementing a JavaTM Virtual Machine in the Java Programming Language Antero
Taivalsaari, SMLI TR-98-64 March 1998
4. ) ³Proceedings of the, 2nd JavaTM Virtual Machine ,Research and Technology
Symposium
(JVM '02), San Francisco, California, USA, August 1-2, 2002 ,THE ADVANCED.

5. THE STRUCTURE OF THE JAVA VIRTUAL MACHINE,page.


6. INSIDE THE JAVA VIRTUAL MACHINE, Filip Hanik, Covalent Technologies August .6
.29, 2007
7. DynamicClass Loading in the JavaTM VirtualMachine Sheng Liang Gilad Bracha
SunMicrosystems Inc.
8. Introduction to java Sang Shin ,Michèle Garoche, www.javapassion.com , “Learn with
Passion!”
9. Speculative Multithreading in a Java Virtual Machine , Sable Technical Report No.
2005-1
Christopher J.F. Pickett and Clark Verbrugge

You might also like