1.

The JVM is a crucial component of the Java Platform

Because JVMs are available for many hardware and software platforms, Java can be both
middleware and a platform in its own right — hence the expression "write once, run
anywhere." 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.

The Java platform is the name for a bundle of related programs, or platform, from Sun
Microsystems which allow for developing and running programs written in the Java
programming language. The platform is not specific to any one processor or operating
system, but rather, an execution engine (called a virtual machine) and a compiler with a
set of standard libraries are implemented for various hardware and operating systems so
that Java programs can run identically on all of them.

A virtual machine is software that creates a virtualized environment between the

computer platform and its operating system, so that the end user can operate software on
an abstract machine.

2. A Java Virtual Machine (JVM) is a set of computer software programs and data
structures which implements a specific virtual machine model.

This model accepts a form of computer intermediate language, commonly referred to as

Java bytecode, which conceptually represents the instruction set of a stack-oriented,
capability architecture. This code is most often generated by Java language compilers,
although the JVM can also be targeted by compilers of other languages.

Java bytecode is the form of instructions that the Java virtual machine executes. Each
bytecode instruction is one byte in length (hence the name), thus the number of bytecodes
is limited to 256.

3. The Java Virtual Machine has a stack-based architecture

A stack is a temporary abstract data type and data structure based on the principle of Last
In First Out (LIFO).

4.Bytecode instructions

A monitor is an approach to synchronizing two or more computer tasks that use a shared
resource, usually a hardware device or a set of variables.

Exception handling is a programming language construct or computer hardware

mechanism designed to handle the occurrence of some condition that changes the normal
flow of execution. The condition is called an exception. Exceptions are used only for
signaling error (exceptional) conditions.
Subroutine (function, method, procedure, or subprogram) is a portion of code within a
larger program, which performs a specific task and is relatively independent of the
remaining code. The syntax of many programming languages includes support for
creating self contained subroutines, and for calling and returning from them.

A branch is a point in a computer program where the flow of control is altered. The term
branch is usually used when referring to a program written in machine code or assembly
language; in a high-level programming language, branches usually take the form of
conditional statements, subroutine calls or GOTO statements.

Dynamic memory allocation is the allocation of memory storage for use in a computer
program during the runtime of that program. It is a way of distributing ownership of
limited memory resources among many pieces of data and code.

Type conversion or typecasting refers to changing an entity of one data type into another.
This is done to take advantage of certain features of type hierarchies. For instance, values
from a more limited set, such as integers, can be stored in a more compact format and
later converted to a different format enabling operations not previously possible, such as
division with several decimal places' worth of accuracy.

Arithmetic is performed according to an order of operations. Any set of objects upon

which all four operations of arithmetic can be performed (except division by zero), and
wherein these four operations obey the usual laws, is called a field.

5.What is JVM?

Acronym for Java Virtual Machine. An abstract computing machine, or virtual machine,
JVM is a platform-independent execution environment that converts Java bytecode into
machine language and executes it. Most programming languages compile source code
directly into machine code that is designed to run on a specific microprocessor
architecture or operating system, such as Windows or UNIX. A JVM -- a machine within
a machine -- mimics a real Java processor, enabling Java bytecode to be executed as
actions or operating system calls on any processor regardless of the operating system. For
example, establishing a socket connection from a workstation to a remote machine
involves an operating system call. Since different operating systems handle sockets in
different ways, the JVM translates the programming code so that the two machines that
may be on different platforms are able to connect.

6.Working of JVM

At the heart of the Java platform lies the Java Virtual Machine, or JVM. Most
programming languages compile source code directly into machine code, suitable for
execution on a particular microprocessor architecture. The difference with Java is that it
uses bytecode - a special type of machine code.
Java bytecode executes on a special type of microprocessor. Strangely enough, there
wasn't a hardware implementation of this microprocessor available when Java was first
released. Instead, the processor architecture is emulated by what is known as a "virtual
machine". This virtual machine is an emulation of a real Java processor - a machine
within a machine (Figure One). The only difference is that the virtual machine isn't
running on a CPU - it is being emulated on the CPU of the host machine.

The Java Virtual Machine is responsible for interpreting Java bytecode, and translating
this into actions or operating system calls. For example, a request to establish a socket
connection to a remote machine will involve an operating system call. Different operating
systems handle sockets in different ways - but the programmer doesn't need to worry
about such details. It is the responsibility of the JVM to handle these translations, so that
the operating system and CPU architecture on which Java software is running is
completely irrelevant to the developer.

The Java Virtual Machine forms part of a large system, the Java Runtime Environment
(JRE). Each operating system and CPU architecture requires a different JRE. The JRE
comprises a set of base classes, which are an implementation of the base Java API, as
well as a JVM. The portability of Java comes from implementations on a variety of CPUs
and architectures. Without an available JRE for a given environment, it is impossible to
run Java software.

ANOTHER APPLICATION ON JVM:

The Java Virtual Machine, or JVM, is an abstract computer that runs compiled Java
programs. The JVM is "virtual" because it is generally implemented in software on top of
a "real" hardware platform and operating system. All Java programs are compiled for the
JVM. Therefore, the JVM must be implemented on a particular platform before compiled
Java programs will run on that platform.

The JVM plays a central role in making Java portable. It provides a layer of abstraction
between the compiled Java program and the underlying hardware platform and operating
system. The JVM is central to Java's portability because compiled Java programs run on
the JVM, independent of whatever may be underneath a particular JVM implementation.
What makes the JVM lean and mean? The JVM is lean because it is small when
implemented in software. It was designed to be small so that it can fit in as many places
as possible -- places like TV sets, cell phones, and personal computers. The JVM is mean
because it of its ambition. "Ubiquity!" is its battle cry. It wants to be everywhere, and its
success is indicated by the extent to which programs written in Java will run everywhere.

Java bytecodes
Java programs are compiled into a form called Java bytecodes. The JVM executes Java
bytecodes, so Java bytecodes can be thought of as the machine language of the JVM. The
Java compiler reads Java language source (.java) files, translates the source into Java
bytecodes, and places the bytecodes into class (.class) files. The compiler generates one
class file per class in the source.

To the JVM, a stream of bytecodes is a sequence of instructions. Each instruction consists

of a one-byte opcode and zero or more operands. The opcode tells the JVM what action
to take. If the JVM requires more information to perform the action than just the opcode,
the required information immediately follows the opcode as operands.

A mnemonic is defined for each bytecode instruction. The mnemonics can be thought of
as an assembly language for the JVM. For example, there is an instruction that will cause
the JVM to push a zero onto the stack. The mnemonic for this instruction is iconst_0, and
its bytecode value is 60 hex. This instruction takes no operands. Another instruction
causes program execution to unconditionally jump forward or backward in memory. This
instruction requires one operand, a 16-bit signed offset from the current memory location.
By adding the offset to the current memory location, the JVM can determine the memory
location to jump to. The mnemonic for this instruction is goto, and its bytecode value is
a7 hex.

The "virtual hardware" of the Java Virtual Machine can be divided into four basic
parts: the registers, the stack, the garbage-collected heap, and the method area.
These parts are abstract, just like the machine they compose, but they must exist in some
form in every JVM implementation.
The size of an address in the JVM is 32 bits.The JVM can, therefore, address up to 4
gigabytes (2 to the power of 32) of memory, with each memory location containing one
byte. Each register in the JVM stores one 32-bit address. The stack, the garbage-collected
heap, and the method area reside somewhere within the 4 gigabytes of addressable
memory. The exact location of these memory areas is a decision of the implementor of
each particular JVM.

A word in the Java Virtual Machine is 32 bits. The JVM has a small number of primitive
data types: byte (8 bits), short (16 bits), int (32 bits), long (64 bits), float (32 bits), double
(64 bits), and char (16 bits). With the exception of char, which is an unsigned Unicode
character, all the numeric types are signed. These types conveniently map to the types
available to the Java programmer. One other primitive type is the object handle, which is
a 32-bit address that refers to an object on the heap.

The method area, because it contains bytecodes, is aligned on byte boundaries. The stack
and garbage-collected heap are aligned on word (32-bit) boundaries.

The proud, the few, the registers

The JVM has a program counter and three registers that manage the stack. It has few
registers because the bytecode instructions of the JVM operate primarily on the stack.
This stack-oriented design helps keep the JVM's instruction set and implementation
small.

The JVM uses the program counter, or pc register, to keep track of where in memory it
should be executing instructions. The other three registers -- optop register, frame
register, and vars register -- point to various parts of the stack frame of the currently
executing method. The stack frame of an executing method holds the state (local
variables, intermediate results of calculations, etc.) for a particular invocation of the
method.

The method area and the program counter

The method area is where the bytecodes reside. The program counter always points to
(contains the address of) some byte in the method area. The program counter is used to
keep track of the thread of execution. After a bytecode instruction has been executed, the
program counter will contain the address of the next instruction to execute. After
execution of an instruction, the JVM sets the program counter to the address of the
instruction that immediately follows the previous one, unless the previous one
specifically demanded a jump.

The Java stack and related registers

The Java stack is used to store parameters for and results of bytecode instructions, to pass
parameters to and return values from methods, and to keep the state of each method
invocation. The state of a method invocation is called its stack frame. The vars, frame,
and optop registers point to different parts of the current stack frame.

There are three sections in a Java stack frame: the local variables, the execution
environment, and the operand stack. The local variables section contains all the local
variables being used by the current method invocation. It is pointed to by the vars
register. The execution environment section is used to maintain the operations of the
stack itself. It is pointed to by the frame register. The operand stack is used as a work
space by bytecode instructions. It is here that the parameters for bytecode instructions are
placed, and results of bytecode instructions are found. The top of the operand stack is
pointed to by the optop register.

The execution environment is usually sandwiched between the local variables and the
operand stack. The operand stack of the currently executing method is always the
topmost stack section, and the optop register therefore always points to the top of the
entire Java stack.

The garbage-collected heap

The heap is where the objects of a Java program live. Any time you allocate memory with
the new operator, that memory comes from the heap. The Java language doesn't allow
you to free allocated memory directly. Instead, the runtime environment keeps track of
the references to each object on the heap, and automatically frees the memory occupied
by objects that are no longer referenced -- a process called garbage collection.
;’/l.kdjgdf[op iyh’/goiudyth egehng[operit7yt55