Wednesday, September 1, 2010

The Architecture of the Java Virtual Machine

Java Virtual Machine

Java Virtual Machine like its real counter part, executes the program and generate output. To execute any code, JVM utilizes different components.

JVM is divided into several components like the stack, the garbage-collected heap, the registers and the method area. Let us see diagram representation of JVM.

The Stack

Stack in Java virtual machine stores various method arguements as well as the local variables of any method. Stack also keep track of each an every method invocation. This is called Stack Frame. There are three registers thats help in stack manipulation. They are vars, frame, optop. This registers points to different parts of current Stack.

There are three sections in Java stack frame:
Local Variables

The local variables section contains all the local variables being used by the current method invocation. It is pointed to by the vars register.
Execution Environment

The execution environment section is used to maintain the operations of the stack itself. It is pointed to by the frame register.
Operand Stack

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.
Method Area

This is the area where bytecodes reside. The program counter points to some byte in the method area. It always keep tracks of the current instruction which is being executed (interpreted). After execution of an instruction, the JVM sets the PC to next instruction. Method area is shared among all the threads of a process. Hence if more then one threads are accessing any specific method or any instructions, synchorization is needed. Synchronization in JVM is acheived through Monitors.
Garbage-collected Heap

The Garbage-collected Heap is where the objects in Java programs are stored. Whenever we allocate an object using new operator, the heap comes into picture and memory is allocated from there. Unlike C++, Java does not have free operator to free any previously allocated memory. Java does this automatically using Garbage collection mechanism. Till Java 6.0, mark and sweep algorithm is used as a garbage collection logic. Remember that the local object reference resides on Stack but the actual object resides in Heap only. Also, arrays in Java are objects, hence they also resides in Garbage-collected Heap.

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 5-1 shows a block diagram of the Java virtual machine that includes the major subsystems and memory areas described in the specification. As mentioned in previous chapters, 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.

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.

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.

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 5-2 for a graphical depiction of these memory areas.

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.

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.

See Figure 5-3 for a graphical depiction of the memory areas the Java virtual machine creates for each thread. These areas are private to the owning thread. No thread can access the pc register or Java stack of another thread.
READ MORE - The Architecture of the Java Virtual Machine

Java Methods in the Database

Java Methods in the Database

When the database class is created it includes the methods from the original Java class. As a result, SQL commands can include calls to Java methods:

• wherever a value is used - in expressions, select lists, where clauses, etc. (the value of a method call is its return value),
• in the EXECUTE command, as a stored procedure (see Stored Procedures), or
• in the EVALUATE clause of the UPDATE command, to change the state of object columns.

Static method calls can use the form:

[ [ catalog-name . ] schema-name . ] class-name . method-name (...)
class-name must be the database name of a cataloged Java class.
Instance method calls use the form:
( instance-expression ) . method-name (...)

instance-expression is a SQL expression returning an object. It could be:

• a reference to an object column,
• a call to a method returning a database object,
• a NEW clause creating a new database object, or
• the result of a CAST operator casting one of the above expressions to a database class; a ? placeholder can also be cast to a database class.

Note: you can omit the parentheses for a reference to an object column, in most cases.

In the rows of the database table, the value of a column defined with Java class is an instance (object) of the Java class. Instances are created using the constructor for the class. Column values are active instances and their methods are callable in SQL commands. When the client retrieves a column value defined as a Java class, it is an active object that is often executed in the Client's JVM. Both class and instance methods may be accessible.

Stored Procedures in Java

Since the beginning, stored procedure languages have been proprietary to each database vendors, with no commonality. Using more portable languages, like C++, for server procedures has raised issues of safety (an errant procedure could crash the server) and security. Now, with most DB vendors supporting it, Java is becoming the stored procedure language of choice, promising portability and safety.

Stored procedures can be implemented as Java methods. A client application calls a Java stored procedure through JDBC or ODBC using standard syntax. The server translates this syntax into direct calls to user defined Java methods cataloged on the server.

Stored procedures access the database using JDBC and they can return basic values and Java objects. Java objects can include individual JDBC result sets or JDBC statements containing multiple results.
See the FIRSTSQL/J STORED PROCEDURE EXAMPLE at the end of this tutorial

The static methods of a database class are callable as stored procedures:

EXECUTE ? = Money.convert(?, ‘Euro’)

Stored procedures also support output parameters in the form of Java objects. The stored procedure can modify an object passed as a parameter and return the modified object to the caller (the client). The Java object must be derived from a Java class cataloged in the database.

Java servlets are an excellent fit for a Java stored procedure:

• Portability - Java database servlets can be written in pure Java using standard JDBC for database access.
• Safety - Java code is free from pointer misuse and memory leaks. The JVM (Java Virtual Machine) applies the sandbox approach to executing Java code, restricting external access.
• Security - The JVM sandbox mechanism provides secure execution of Java code. The JVM also supports authentication of Java database servlets.

With a portable stored procedure language, code can be transferred between servers and JVMs from different vendors, vendor-specific training is reduced and database-independent applications can be distributed with application-specific stored procedure code.
READ MORE - Java Methods in the Database
 
THANK YOU FOR VISITING