The Java Virtual Machine

Amrish Lal

Janet Formichelli

Advanced Programming Languages

Kent State University

December 1, 1998

2

Table of Contents1 INTRODUCTION ........................................................................................................................... 3

2 OVERVIEW OF JAVA VIRTUAL MACHINE [5, 10] ................................................................. 3

3 SOME SPECIFIC FEATURES OF JVM....................................................................................... 4

3.1 JAVA CLASS FILES [5]................................................................................................................. 43.2 CONSTANT POOL [5]................................................................................................................... 53.3 JAVA VIRTUAL MACHINE INSTRUCTION SET [5] .......................................................................... 53.4 DATA TYPES IN JAVA VIRTUAL MACHINE [5] .............................................................................. 63.5 JAVA STACK ,OPERAND STACK, AND STATE VARIABLES [5] ........................................................ 63.6 METHOD INVOCATION AND RETURN [5, 11]................................................................................. 73.7 JAVA RUNTIME SYSTEM [5] ........................................................................................................ 7

4 COMPONENTS OF JAVA RUNTIME SYSTEM ......................................................................... 8

4.1 CLASS LOADER [5, 12] ............................................................................................................... 84.2 SECURITY MANAGER AND JAVA ’ S SECURITY MODEL [5, 12, 13].................................................. 84.3 ERROR AND EXCEPTION MANAGER [5]...................................................................................... 104.4 NATIVE METHOD SUPPORT [5, 11]............................................................................................ 104.5 THREADS INTERFACE [5, 14] .................................................................................................... 104.6 MEMORY MANAGER ................................................................................................................ 114.7 EXECUTION ENGINE ................................................................................................................. 13

5 JUST-IN-TIME COMPILATION OF JAVA BYTECODES [5, 10] ............................................ 13

5.1 MINIMIZING THE COMPILATION OVERHEAD ............................................................................... 145.2 GENERATING EFFICIENT CODE................................................................................................... 145.3 INTERACTIONS WITH THE JVM.................................................................................................. 15

6 HARDWARE IMPLEMENTATION OF JAVA VIRTUAL MACHINE .................................... 15

6.1 TRANSLATING BYTECODE......................................................................................................... 156.2 EMBEDDED SYSTEMS............................................................................................................... 166.3 SUN’ S JAVA PROCESSOR........................................................................................................... 166.4 THE INSTRUCTION SET ............................................................................................................. 166.5 STACK PROCESSING................................................................................................................. 176.6 HIGH- AND LOW-WATER MARKS.............................................................................................. 186.7 PICOPERC ............................................................................................................................... 18

7 COMPETITORS IN THE JAVA VIRTUAL MACHINE MARKET ......................................... 18

7.1 NEWMONICS............................................................................................................................ 187.2 MICROSOFT AND HEWLETT-PACKARD ...................................................................................... 187.3 RTOS VENDORS...................................................................................................................... 197.4 EMBEDDEDJAVA ...................................................................................................................... 19

8 CRITICAL ANALYSIS OF JAVA PROGRAMMING SYSTEM ............................................... 20

9 CONCLUSION ............................................................................................................................. 21

10 REFERENCES.......................................................................................................................... 22

3

The Java Virtual Machine

1 Introduction

The Java programming language was developed at Sun Microsystems and is heavilyinfluenced by Sun’s concept of “Network is a Computer.” Originally designed forprogramming small consumer electronic devices such as Personal Digital Assistant(PDA), Java gained in popularity after Netscape decided to incorporate Java into itspopular web browser. Today Java is one of the most popular programming languages.However, the performance disadvantage that Java has when compared to compliedlanguages such as C/C++ and the widespread belief that Java is not suitable fordeveloping large commercial applications has somewhat marred the popularity of Java.

The object oriented nature of Java, its “write once, run anywhere” portability (referred tosome as “write once, debug everywhere”), and built in security features make Java anideal language for use in a widespread, distributed, and heterogeneous system like theInternet. These features along with the performance limitations of Java (with respect tocompiled languages such as C) have lead some people to label Java as a programminglanguage that is ahead of its time.

The Java Programming Language is a semi-compiled language. A program written inJava is first complied into bytecode, (like a complied language such as C) which is thenexecuted on a virtual machine (like an interpreted language such as Perl) commonlyknown as Java Virtual Machine (JVM).

In this paper, we are going to provide a detailed overview of the JVM architecture anddescribe the component of JVM that allow for executing a Java class file (or bytecodes)with the same consistency and security on machines with completely different hardwarearchitectures. We assume that the reader is familiar with writing Java programs and isknowledgeable about the features of Java Programming Language. This paper alsodescribes a new technology known as Pico Java, recently announced by Sun, whichimplements the JVM in hardware.

2 Overview of Java Virtual Machine [5, 10]

Java programs are not run directly by the CPU or a computer, instead a virtual processor(or JVM) runs them, which is a piece of software running on the computer. JVM, at itscore, is an interpreter with its own instruction set. The Java class files contains anexecutable program written using JVM’s instruction set. JVM simply reads theinstructions contained in a class files and executes these instructions as it encountersthem (with exceptions as in the case of Java’s Just In Time (JIT) compiler describedlater).

The features of Java Programming Language are directly based on the specification ofJVM. JVM is a virtual machine; hence it allows for portability of Java Programs. Insteadof porting each individual program (as in the case of a C program with graphical user

4

interface) to different machine architectures, we only need to port the virtual machine todifferent machine architecture. After the virtual machine has been ported there is no needto modify programs that are build on top of the virtual machines. Virtual machines, suchas JVM, also offer a layer or protection between the computer and the software program.This allows for security features, in Java programming language that prevents programsfrom acting maliciously.

To run a Java program, the JVM first loads the class file, using the Class Loader, thatcontains the program entry point and begins executing that class file, invoking onemethod after another as specified in the class file. New class Files are loaded, possiblyover the network, by the JVM as encountered in the original class file. The finalassociation of class files takes place as the program is running (dynamic linking). Beforeexecuting a class file that was just loaded over the network, JVM performs severalconsistency checks. JVM checks the structure and integrity of the class file using theClass File Verifier. To maintain the integrity of the execution model, JVM checks that avariety of semantic constraints are met, both within a class file and between class files.

As part of the program execution, JVM must provide for various services. JVM mustmanage memory and allow programs to create objects and reclaiming objects that are nolonger being used. Java programs may call native methods; hence, JVM must have built-in support for invoking and passing control to native methods. Error and exceptionconditions may arise during the execution of the program and JVM must deal with these.Java is a threads based language; hence, JVM must provide support for propersynchronization of threads and permitting threads access to shared variable and codeareas. JVM must also ensure that the program being executed is safe and will not causeany damage to the local system.

3 Some Specific Features of JVM

3.1 Java Class files [5]

A complied Java program is saved as bytecodes (or binary data) in class files. These filesare read by JVM before program execution. A Java class file contains the followinginformation:

• Virtual machine code for methods provided by the class.• A symbolic reference to the superclass of the class.• A list of the fields defined by the class.• A “constant pool” containing literals and symbols used by the classes.• Any other data that may be required by the runtime system.

JVM treats class files as a stream of 8-bit, 16-bit, 32-bit, and 64-bit quantities and thefirst item in the class file is the magic number 0xCAFEBABE. A class file is organizedas a set of nested tables. The most essential tables in a class file are:

5

• Top-level table or the outermost table that contains information about the class as awhole, including the name of the class, the identity of the superclass, and accesspermissions of the class.

• Constant-pool table is an ordered set of symbols and literals, numeric constants,references to other classes, method names, field names, and type descriptions.

• Interface table contains a list of interfaces implemented by the class.• Fields table contains a list of fields that this class adds.• Methods table contains a list of methods defined in the class• Attribute table appears at all levels of the class and provides additional information

associated with the class and with fields and methods.

3.2 Constant Pool [5]

Every Java class (and interface) has a constant pool associated with it. Constant pools areequivalent to symbol tables and they represent collection of all the symbolic data neededby a class (symbolic reference to field, classes, interfaces, and methods). References toconstants are stored as 8-bit or 16-bit unsigned integers; hence, maximum number ofconstant pool entries in any class is 65535 (also the maximum number of declarations ina Java class).Constant pool supports dynamic linking. JVM resolves the symbolic reference into aconcrete reference to a runtime data structure as it comes across each entry in theconstant pool.

3.3 Java Virtual Machine Instruction Set [5]

JVM uses an 8-bit instruction opcodes, which limits JVM to 256 instructions and littleroom for expansion (however an escape mode could be used in future for expansion).Many of the instructions found in JVM [Fig. 3] are similar to the kind of instructions thatare available on hardware CPU. This includes instructions for arithmetic, flow control(branches and jumps), accessing elements in array, etc. However, unlike most hardwareCPUs JVM’s virtual processor is stack based and uses numbered local variables insteadof registers as illustrated by the instructions given below for 80x86 processor and JVM.

Instructions for adding two integers in 80x86 machine.

mov AX,5 ; put the number 5 into register AXmov BX,10 ; put the number 10 into register BXadd ; AX = AX + BX

Instructions for adding two numbers in JVM.

bipush 5 ; push number 5 into the stackbipush 10 ; push number 10 into the stackiadd ; add top two numbers on stack leaving result on stackistore_1 ; pop and store the result in local variable 1

6

Several JVM instructions are more complicated than the instructions found on a hardwareprocessor. For example, JVM contains 20 instruction for manipulating Java objects(calling methods, getting and setting fields, allocating new objects, etc.), and theseinstructions are fairly complicated. Implementation of instruction in JVM may requiresupport for garbage collection, exception handling, and loading of classes from local diskor network.

JVM has a comparatively large instruction set. For each different primitive type in Java,there is a set of instruction that operate only with that type. For example there areseparate isub, fsub, dsub, and lsub instructions for substracting integers,floats, doubles, and longs.

3.4 Data Types in Java Virtual Machine [5]

JVM does not have enough instruction opposed to treat all types equally; hence, sometypes have more built-in support than others. Most basic numeric types in the JVM areints, longs, floats, and doubles. Doubles and longs (64 bits) actually occupy two entrieson the operand stack (32 bits. Two local variables (2 x 32 bits) are used to store the valueof double and long variables. Byte, short, and char are refereed to as storage types and donot have as much support as int, float, and doubles. JVM also does not contain anyboolean type. Boolean in JVM is represented using 0 for false and 1 for true.

JVM contains several instructions for manipulating Java objects and arrays. Arrays aretreated as objects in JVM.

3.5 Java Stack ,Operand Stack, and State Variables [5]

JVM is a stack-based machine. One of the most important stacks in JVM is referred to asthe Java Stack. The Java Stack consists up of Frames or activation records of methodsthat are invoked while a Java program is running. A Frame is created on Java Stack whena method is invoked. When the method returns, the Frame is discarded.

Frame consists up of an Operand Stack and local variables needed to execute a method.Frames also hold other state variables such as the pc (program counter), a pointer to theclass of the currently executing method, and a pointer to the invoker’s frame.

Operand Stack consists up of 32-bit quantities and instructions receive values and returnresult using the operand stack. The JVM interpreter is responsible for transferring returnvalues from its own operand stack to the operand stack of the caller.

Local Variables correspond to named variables used in a Java program. However, localvariables in JVM are numbered and instruction to manipulate local variable takes aninteger operand indicating which variables to use. Each local variable is 32-bits wide. InJVM numeric variables are passed using call-by-value method and call-by-reference isused to pass objects.

7

JVM does not provide any general-purpose registers. However, execution engines domaintain state information using State Variables. State information includes a stack-topindex, thread state information, a pointer to the current method being executed, a pointerto that method’s class and constant pool, a stack-frame pointer, and a program counterthat indicates the instruction in bytecode that is being executed.

3.6 Method invocation and return [5, 11]

There are two types of methods in Java: Instance methods and class (or static) methods.Instance methods require an instance before they can be invoked; while as, class methoddo not. Instance method use dynamic binding while as class methods use static binding.There are separate instruction in the JVM instruction set to invoke static methods(instruction: invokestatic) and instance methods (instruction: invokevirtual). Theseinstruction refer to the a constant pool entry that is a reference for a method.

When such an instruction is encountered in a class files, JVM’s execution engine, itresolves the constant pool entry for the method to be invoked. The symbolic reference inthe constant pool is replaced by a direct reference to a direct reference to the method.JVM also performs several consistancy checks during resolution to ensure that the invokeinstruction is safe to execute and that the current class can legally access the method. Ifany of these checks fail an exception is raised.

Once the method is resolved, JVM is ready to invoke that method. In case of an instancemethod, the object reference for which the method is being executed and the argumentsof the methods must be on the stack before the method can be executed. Incase of a classmethod, only the arguments need to be on the stack. To invoke a method, JVM’sexecution engine creates a new stack frame and pushes this stack frame into the JavaStack. In case of native methods, no stack frame is created instead the programs control ispassed to the native method.

When the method returns the return value is popped off from the operand stack of themethod that was called and placed into the operand stack of the calling method’s stackframe. The stack frame of the method that was called is then popped from the Java Stackand discarded.

3.7 Java Runtime System [5]

An implementation of JVM is known as Java Runtime System (JRS). Applicationprograms such as Netscape Communicator and Microsoft’s Internet Explorer that areJava-enabled applications have the JRS embedded in them.

A typical JRS includes the following sub-components (Fig. 1)

• Execution Engine is the virtual (or hardware processor as in the case of Pico Java)that executes the bytecodes.

• Memory Manager for allocating memory for objects and garbage collection.

8

• Error and Exception Manager for dealing with catching and throwing exceptions.• Native Method Support for calling functions or methods written in C/C++.• Threads Interface for supporting threads and monitors.

• Class Loader for dynamically loading Java classes from a class file.• Security Manager for verifying that classes are safe and for controlling access to

system resources.

The JRS also includes a set of standard Java classes, that provide support for strings,numbers, files, and so on. 20 of these classes are highly implementation dependent andact as an interface to the operating system. These classes provide support for accessingthe network, windowing environment, threads, and local file systems.

4 Components of Java Runtime System

4.1 Class Loader [5, 12]

Before JVM can execute a Java program it must load the classes that make up the Javaprogram. Class loading in JVM is dynamic. This implies that classes are loaded as theyare encountered in a Java Program being executed. If a class is no longer needed (if thereare no object instances of a class) then that class is unloaded and garbage collected.JVM’s Class loader can load classes from a file on the local disk, or over a network, or bydynamically generating a byte array.

A JRS allows for two mechanisms for loading classes: A System Class Loader and acustomized class loader that is extended from the Java Class ClassLoader.java. ClassLoader searches for a class in the order given below:

• First, the current directory is searched for the class

• Second, the classes that come with Java Distribution (JDK) are searched for the givenclass.

• Third, all the directories, ZIP files, and JAR files that are listed in CLASSPATHenvironment setting are searched.

• Fourth (for applets only), The location specified by the CODEBASE parameter of theapplet is searched.

4.2 Security Manager and Java’s Security Model [5, 12, 13]

Java’s security model protects users from hostile programs downloaded from untrustedsources across the network. JVM provides a customizable sandbox in which Javaprograms execute. The sandbox does not allow a Java applet to:• Read or write files to the local disk• Make network connection to any host, expect the host from which the program came

from.• Creating new processes

9

• Loading dynamic libraries and calling native methods.

Java application programs are considered to be trusted and not subjected to such securitylimitations. JVM’s Classloader is the first line of defense against malicious applets bynot allowing malicious programs to interact with trusted code and by not allowing themalicious programs to access class libraries. The JVM Class Loader also usesnamespaces to remember where a class was loaded. A class can only inteact with otherclasses in the same namespace; thereby, preventing a malicious program to access otherclasses.

The second line of defense against malicious applets is the JVM’s Class File Verifier.The Class File Verifier ensures that classes loaded by the Class Loader have properinternal structure. Class Verifier throws an exception if it discovers a problem with theclass file. As part of the verification of the class files, the verifier ensures that all thejump instructions in the program cause the control flow to pass to another validinstruction.

The verifier works in two phases. In the first phase, it performs a series of internalchecks. In this phase, the verifier tries to check everything in the class file by looking atthe class file only. The verifier checks for the integrity of the bytecodes, the majicnumber in the class file (0xCAFEBABE). Verifier also checks whether the class file hasbeen truncated or enhanced by extra bits, ensure that individual components are wellformed, and also checks if the class adheres the constraints placed by the specification ofthe Java Language (for example, every class, except Object must have a superclass).

After checking for consistency, integrity, and format of the class files the verifierperforms check data-flow analysis on bytecode that represent the methods of a class.Verifier ensures that no matter what execution path is taken the operand stack containssame number and types of item. It checks if opcodes being used in the program are legaland that each opcode has valid operands. Numerous such checks are performed.

In phase two of the verification proces symbolic references are verified after bytecode inclass files are executed. The JVM follows the references from the class file being verifiedto the referenced class files, to make sure the references are correct. In phase two theverifier also looks at classes that refer to one another to make sure that these class filesare compatible with each other (for example, if one class being referred to is changedthen the classes may not be compatible with each other).

JVM provides for a highly integrated security model, since the entire JVM was developedwith security of programs downloaded over the network in mind. The Security Managerin JVM performs verification of the class files and ensures that the program adhears to itssecurity restriction. The Security Manager controls access to resources that an applet mayaccess, such as disk, dynamic libraries on the local system, operating systems resources,and others.

10

4.3 Error and Exception Manager [5]

Exceptions are Java’s way of signaling that something is wrong. Exceptions can signalrecoverable situations such as EOFException (end of file exception) or fatal situationssuch as OutOfMemoryError (JRS ran out of memory while executing the program). JVMand methods in a Java program can raise exceptions and Error conditions.

At the JVM level, each method defines an Exception Handler Table. The exceptionhandler table is maintained by JVM’s exception manager and lists exception each methodcatches. The exception manager’s main responsibility is to process runtime exceptions.

When an exception is thrown, the exception manager searches for a handler for thatexception in the following order:

• The method that generated the exception. If no handler is found the current methodframe is discarded from the Java Stack.

• The method that invoked the current method is searched for the exception handler.

Frames for each method in the invocation hierarchy are searched and discarded as theexception manager attempts to locate at exception handler. If an exception handler isfound, the exception manager clears the operand stack, pushes the exception object ontothe stack, and then continues execution from the address of the handler.

4.4 Native Method Support [5, 11]

Native methods are complied code specific to a particular hardware machine that can beaccessed by a Java program while it is running. JVM includes support to dynamicallyload and execute the code in native methods by using operating systems call that access adynamic library (DLLs on Windows NT, shared library on UNIX, etc). After the nativemethods are linked to the JRS, the execution engine traps calls to the native method andredirects these calls to the underlying native code. The process involves marshallingarguments in the form that can be used by the native code and transferring programcontrol to the native method. After the native method returns, results are put back into thecorresponding Java types and inserted into the operand stack of the calling Java method.

4.5 Threads Interface [5, 14]

In JVM, each thread is given its own Java Stack, which contains data that no other threadcan access (local variables, parameters, return values of methods that the thread hasinvoked, etc). The data on stack is limited to primitive types and object references and theobjects actually reside in the heap. The JVM heap is shared by all the threads.

Besides the Java Stack and the JVM heap data can also be stored in method area. Themethod area contains all the static variables used by the program and static variables thatare shared by all the threads.

11

The JVM’s Thread Interface coordinates access to the shared variables in the heap and inthe method area. Each object and class has a lock associated with it. Each thread requestsa lock from the JVM before it accesses the object. After getting the lock the thread usesthe object and once it is done using that object, it returns the lock to JVM. A thread isallowed to lock a method multiple times. JVM also uses monitors. Monitor ensures thatonly one thread at a time executes a given block of code.

Using locks and monitors, JVM’s Thread Interface supports synchronization betweenvarious active threads that may need access to a shared method.

4.6 Memory Manager

Java Virtual Machine Specification

The Java Virtual Machine Specification says very little about garbage collection. It onlystates, “Heap storage for objects is reclaimed by an automatic storage managementsystem (typically a garbage collector); objects are never explicitly deallocated.” [3, p.63] Since this is only an abstract machine specification it leaves the particular garbage-collection algorithm up to those who implement it.

Why Garbage Collection?

Although memory is larger today, it is still a finite resource. Garbage collection isnecessary to avoid running out of memory space. Garbage collection implies that objectsthat are no longer being used can be thrown away. A better metaphor might be memoryrecycling, reclaiming memory space on the heap for reuse.

Heap fragmentation is another issue that is usually considered in the garbage collectionimplementation. If there is not enough contiguous free space the performance of thesystem can be degraded. In virtual memory systems it can result in extra paging orswapping. In an embedded system, where memory resources are more limited, the virtualmachine could run out of memory.

Garbage collection liberates programmers from worrying about freeing memory. It alsoensures that they can not accidentally crash the system. On the other hand, it givesprogrammers less control over scheduling the CPU time devoted to garbage collection. [9, pp. 264-265]

Tracing Collectors

Tracing garbage collectors start at a set of root nodes and determine whether objects arereachable from these roots. If an object is reachable it is marked as a live object. This isthe mark phase of the mark-and-sweep algorithm. In the sweep phase unmarked objectsare freed and their memory space is made available. [9, p. 267]

12

In Java the garbage collector is also responsible for running any finalizers of objects thatare to be freed. A finalizer is a method, which may be included with an object, that mustbe run prior to garbage collection. The sweep phase must include finalization of objects.Programmers can not predict when a finalizer will be run because they have no controlover when garbage collection will be done. [9, p. 271-272]

Compacting Collectors

One strategy commonly used by mark-and-sweep collectors to avoid heap fragmentationis to compact all live objects to one end of the heap, leaving a large, contiguous free areaat the other end.

Updating references to moved objects is often accomplished by using handles (see figure6). Object references are made to a table of object handles which refer to the actualobjects. When an object is moved, only the handle must be updated. All references to theobject are through the handle and do not have to be changed. This simplifies heapdefragmentation but adds a level of overhead. [9, p.268]

Copying Collectors

Copying collectors move all live objects to a new area, leaving forwarding pointersbehind (see figure 5). No mark-and-sweep is necessary. The cost, however, is that twiceas much memory is needed. [9, pp. 268-269]

Generational Garbage Collection

Usually garbage collection must run atomically, meaning that it can not be interrupted.This slows down processing. One partial solution to this problem is generational garbagecollection. It works on the premise that most objects live only a short time. Therefore, themost recently created objects are kept in a portion of memory called the nursery. Insteadof scanning the whole memory, the garbage collector only scans the nursery. As objectsremain there longer, they are moved to older areas of memory.

Garbage Collection on Embedded Systems

Because the virtual machine is in charge of garbage collection there can be no guaranteedresponse time. This is a problem for embedded systems which involve real timeprocessing. “If a real-time task is running, the garbage collector either interrupts it, whichviolates real-time policies, or waits, in which case the system may run out of memorybefore the task completes.” [8, p. 76] Several companies have addressed this problem.

Integrated Systems has developed pSOS which adds a Java Virtual Machine on top of areal time operating system (RTOS) kernel. It can do asynchronous garbage collection. Itskernel can assign priority to a task and so decide when to do garbage collection. Thisgroup had to modify Sun’s Java Virtual Machine implementation in order to achieve thisresult. [2, p. 83]

13

Some implementations of the Java Virtual Machine in hardware provide support forgarbage collection in hardware so that real-time processing is possible. NewMonics’PERC provides a memory copy scheme supported by hardware. [8, p. 76]

Generational garbage collection is employed by a hardware implementation of the JavaVirtual Machine called picoJava, developed by Sun Microsystems. The hardware is ableto keep track of the intergenerational pointers necessary for this method of garbagecollection, thereby supporting very short maximum pause times. [4, pp. 29,30]

4.7 Execution Engine

Execution engine is the heart of the JVM. It takes a stream of bytecodes and executes theinstruction in the bytecodes. The execution engine can be implemented in software,hardware, or a combination of software and hardware. Sun’s initial release of JVMincluded a software interpreter as the execution engine (JDK 1.0 to JDK 1.1.x). Recentimplementations of JVM include a Just-In-Time (JIT) compiler (JDK 1.2) which convertsthe instruction into native methods specific to a hardware architecture and then executesthese native method. A third implementation of the execution engine utilizes hardwareprocessors specifically designed to execute Java bytecodes efficiently.

Execution engines based on software interpreters are conceptually simple. Such anexecution engine reads opcodes from a Java class file and executes the machine codeinstructions corresponding to these opcodes one by one.

Execution engines based on JIT technology are more complex. Just like static programcompilers, JIT generates native code from the instructions in a class file. JIT compilationgreatly speeds up the execution of a Java program as compared to a software interpreterbased execution engine. JIT based execution engine for JVM is described in detail inSection 6.

Execution engine based on specialized hardware processors that execute instructions in aJava program are even faster, since support for executing engine is built into thehardware. Sun recently announced the developed of picoJava chips that areimplementation of the JVM’s execution engine in hardware. Hardware based executionengines for JVM are described in detail in the section 7.

5 Just-In-Time Compilation of Java bytecodes [5, 10]

JIT complier converts bytecodes into native code at a very fast rate by ignoring severalprogram code optimizations that static compilers perform. Java methods and code areconverted into native methods when they are encountered for the first time. After that,instead of executing the instruction using an interpreter, whenever a call to a Java methodis encountered and the corresponding native version of that method is executed.

14

5.1 Minimizing the compilation overhead

JIT compilers work dynamically. They translate each method as it is encountered for thefirst time; hence, to ensure that the java program executes quickly, it is important to avoidunnecessary optimization during compilation. In many compilers constructing anintermediate representation (IR) of a method is a standard process. This process can beeliminated while compiling Java bytecodes, since bytecodes are themselves an IR. Javabytecodes are not ideal IR for compilation, but they can be used for that purpose. Withfew exception, Java bytecodes provide all the information necessary for effectivecompilation.

The stack oriented nature of bytecodes is well suited for interpretation, but not forexecution on a register-based processor. Explicit use of a stack on a register-basedmachine would introduce additional overhead and would fail to take advantage of theregisters. Hence, JIT compilers use bytecodes as implicit encoding of instructions ratherand literal descriptions of the code to be executed.

Traditional compilers use Directed acyclic graphs (DAG) to represent expression. A JITcompiler could easily convert bytecodes into DAGs, but overhead is avoided by directlygenerating machine code from bytecodes.

5.2 Generating efficient code

Three major issues associated with transforming bytecodes directly into efficient machineinstructions are:

• The use of operand stack constrains the order of evaluation specified by thebytecodes. More efficient orderings may be possible on a register-based processor.

• The best choice of machine instruction for a bytecode may depend on how the resultof that bytecode is used.

• The bytecodes may include redundant information.

Java bytecode orderings may not be the optimal choice to determine the order ofevaluation. Other orderings may be more suitable for a processor and require less storageto hold intermediate results. The Java language specifies a particular evaluation order forexpressions so that a compiler can only reorder operations in ways that conform to thespecification.

Some bytecodes are best translated into machine instruction in combination with otherbytedoes that use their results.

Java bytecodes also include redundant information. For example, bytecode may load thesame value from a constant pool several times and a local variable may be pushed intothe operand stack more than once. Finding such redundancies with a basic block andavoiding them will increase performance of JIT. However, it is computationally

15

expensive to find redundancies among basic blocks and it is not yet sure whether a JITcompiler should attempt to find such redundancies.

The JIT compiler generates native code after addressing each of these issues

5.3 Interactions with the JVM

Native code generated by the JIT compiler must interact with the JVM in the followingways:

• Bytecodes involving memory allocation or synchronization are translated into calls toJVM routines.

• Method calls in compiled code may invoke the JVM interpreter, either directly bycalling methods that for some reason are not compiled, or indirectly by calling nativemethods that in turn invoke the interpreter.

• Enteries in constant pool must be resolved when they are first referenced this mayinvolve extensive work in the JVM to load and initialize new classes.

• JVM needs to examine the execution stack for Java methods for exeception handling,garbage collecting and other such tasks. The JVM must locate the stack frames forcompiled methods and know the format of the data within each frame.

The JIT compiler must be careful to generate compiled code that can properly handlesthese interactions.

6 Hardware implementation of Java Virtual Machine

In section 4, we gave a description of the basic components that go into a JRS andmentioned that the execution engine is the core of the JVM. Ever since Java was firstreleased, efforts have been made to increase the performance of Java program (more tosilence the critics of Java rather than to actually increase the performance of Javaprograms). The JIT compilation and picoJava hardware processors are technologies thathold a lot of promise.

6.1 Translating Bytecode

Key to the concept of portability in Java is the idea that Java programs are converted intoclass files that can be executed on any computer. All that is necessary is that thecomputer has a Java Virtual Machine translating the bytecode into the machine code thatthe CPU can then execute. This translation can be done in one of three ways: aninterpreter, a just-in-time compiler or a Java processor. In the latter case the executionengine of the Java Virtual Machine is embedded in the chip and executes the Javabytecode natively. Thus there is no need for dynamic translation.

16

6.2 Embedded Systems

What advantage is there to putting the execution engine of the Java Virtual Machine on achip? One of the main reasons to implement the machine in hardware is to meet the needsof embedded systems. These small computers are everywhere today--in machines to tallybills in grocery stores, to unlock car doors and roll down windows, in microwaves,remote control devices, mobile phones, etc. Projections are that by the year 2010, tentimes as many software developers will be working on embedded devices as will bedeveloping software for desktop computers. [6, p. 50]

These embedded systems use real time operating systems (RTOS) and usually havelimited memory space. As stated above, a hardware implementation of the Java VirtualMachine can work better with an RTOS for garbage collection, allowing the real timeactivities to proceed without being interrupted by the garbage collector. The other majoradvantage of a hardware implementation is that it creates a small memory footprint. Forconsumer electronics products this adds up to savings when products produced inquantity. Also, many of them are small or battery powered and may not need an extensiveset of Java Application Programming Interfaces (APIs). Thus a hardware machine withsmaller memory needs is essential for these systems.

6.3 Sun’s Java Processor

Sun’s implementation of a Java Virtual Machine in hardware is called picoJava. Thecurrent model is picoJava II, which should be available by the end of 1998. Theexecution engine, which translates the bytecode from the class file generated by thecompiler, is called the picoJava core. It contains an integer execution unit and an optionalfloating-point unit. There are separate instruction and data caches.

6.4 The Instruction Set

With picoJava, Sun had to modify somewhat the basic instruction set for the virtualmachine (see figure 3 & 4). The basic set has 226 instructions. These instructions are ofvariable length, with more frequently used instructions having shorter length to improvecode density. The first byte of the instruction is the opcode, followed by operands, ifthere are any. Since the Java Virtual Machine operates stack-to-stack, most often theoperands are to be found on the stack and therefore 62% of the instructions are one byte.

The Java Virtual Machine instruction set was purposely designed differently from that ofa RISC processor. Far fewer instructions would be used on a RISC machine and theywould have a fixed length of four bytes. This approach improves the process of CPUdesign. The Java Virtual Machine was designed from a software point of view andtherefore was developed to create small, secure, platform-independent programs.

The Java Virtual Machine instruction set is intentionally incomplete. Since it is a virtualmachine, there are no instructions to test or diagnose hardware, write CPU status andcontrol registers, or manage on-chip caches. Likewise, to add to Java’s security features,

17

there is no direct access to memory locations. Notice that this means that the Java VirtualMachine itself can not be a Java program.

But when the virtual machine is implemented in hardware, as picoJava is, it is no longervirtual. It is a real machine and thus needs the types of instructions mentioned above thatwere purposely left out of the Java Virtual Machine specification. Therefore there is anew, extended group of instructions designed exclusively for use on this Java processor.No programs written with these extended bytecodes will run on any other processor. Non-Java code can also run on the Java processor. But, unlike Java code running on a virtualmachine, it will be platform-specific and not verifiably secure.

The major reason for the development of the Java CPU is for embedded applications. Sothey must be small and inexpensive, while supporting a large instruction set. To deal withthis design issue, the architects divide instructions into three categories--simple,moderately complicated or very complicated. The simple instructions are RISC-like andare hardwired to execute in one clock cycle. The moderately complicated instructions areimplemented using microcode. The very complicated instructions, such as the newinstruction, may require some operating system assistance. These are implemented insoftware by means of an instruction emulation trap.[4, pp. 24-26]

6.5 Stack Processing

The Java Virtual Machine specification calls for a stack design which is inherently moreinefficient than the use of registers, with up to 30% more operations required formanipulating the stack. The picoJava architects overcome this inefficiency by using acircular buffer as a register file to support stack-based processing. This register file has 3read and 2 write ports. (see Figure ) Procedurally its operation is equivalent to register-to-register operations on a RISC machine.

The reason this works is because of a process called instruction folding. Take theexample of an addition operation. On a RISC machine this can be done with oneinstruction in one clock cycle. On a stack based machine four instructions and clockcycles are necessary. Figure 7 shows the clock cycles for each of the followinginstruction sequences.

RISC Stack-basedADD R3, R2, R1 ILOAD_1 ILOAD_2 IADD ISTORE_3

However instruction folding enables the picoJava core to perform the stack-basedsequence in one cycle also. The core scans the incoming stream of bytecodes foroperations that can be folded together. And since the stack cache in picoJava is, in fact, afull random access register file, there is immediate access to all 64 entries in the cache.The integer add unit can directly access the two operands using the two read ports and

18

return the result directly to the local variable area using the write port. (Again refer toFigure ) Thus picoJava is really comparable to a RISC architecture. [4, pp. 26-28]

6.6 High- and Low-Water Marks

To prevent stalls, spill and fill mechanisms have been incorporated into the stack cache.High- and low- water marks are programmed into the circular buffer that is serving as thestack cache. When the number of valid dirty entries pushed onto the stack reaches thehigh-water mark, the spill mechanism will begin saving them to the data cache, startingwith the oldest. This gives the illusion of infinite register space. Similarly, when the stackshrinks to the low-water mark, the fill mechanism reloads values into the stack from thedata cache. This prevents stalls to reload the cache.[4, p. 27]

6.7 picoPERC

Another implementation of the Java Virtual Machine in hardware is picoPERC (PortableExecutive for Reliable Control), developed by a company called NewMonics. Again,their purpose is to provide a machine for embedded and real-time programmingapplications. The source language for picoPERC is the same as standard Java. It ispossible to run, evaluate and debug picoPERC programs using traditional Java VirtualMachines.

picoPERC has a special ROMizer tool that executes Java bytecodes out of ROM memory.It supports ahead-of-time compilation to native machine language. It provides a MinimalWindows Toolkit one-third the size of Java’s Abstract Windows Toolkit. Its incrementalreal-time garbage collector was described above.

All of this results in a picoPERC core that fits into less than 64 KB of memory. Thecompany boasts that this is less than one-sixteenth of JavaSoft’s Embedded Java, whichwill be described below. [6, pp. 50-51]

7 Competitors in the Java Virtual Machine Market

7.1 NewMonics

As discussed above, NewMonics has created a hardware implementation of the JavaVirtual Machine, picoPERC. This is a clean-room implementation of the Java VirtualMachine, which means that they have implemented the Java language and virtualmachine independently of Sun and without any of Sun’s code. Thus they have avoidedpaying Sun’s fees. [8, p. 75]

7.2 Microsoft and Hewlett-Packard

Hewlett-Packard has released its own small-footprint Java Virtual Machine and licensedit to Microsoft, charging lower licensing fees than Sun. HP’s Java Virtual Machine is

19

only 500 KB, compared to Sun’s 4 MB. Besides being small, this Java Virtual Machinehas a more flexible code base. The entire base would not have to be used with allapplications, as is the case with Sun’s.

As usual, the competition is fierce. Sun claims that HP’s Java Virtual Machine, by usingonly a subset of the Java specification, violates conditions of the Java license. Sun suedMicrosoft recently, claiming it violated its license by optimizing Java for Windows. Ajudge ordered that Microsoft could not use the Java logo because its Java VirtualMachine and Java Developer’s Kit do not meet Sun’s licensing agreement.

Microsoft plans to use HP’s Embedded Machine in its WebTV set-top boxes and inhandheld devices. HP wants to license its virtual machine to others also. Some licenseesmay use it in embedded systems like those in printers and phones, in order to let thesedevices receive and run Java applications over a network. [1, p. 19]

7.3 RTOS Vendors

All major vendors of real-time operating systems are using Java. Many of them arelicensing the Java Virtual Machine from Sun. Microware Systems is using them for set-top boxes and digital cellular phones. Microtec uses them in hubs and routers. WindRiver Systems is focusing on Embedded Java and Personal Java interfaces. [8, p. 75]

Cygnus uses its own GNU technology to do away with the Java Virtual Machineentirely. It compiles directly into native instruction sets. This reduces the code footprintand improves performance, but reduces the cross-platform characteristics of Java. [8,p. 78]

7.4 EmbeddedJava

In the face of all the competition it is receiving from those interested in using Java forembedded devices, Sun has come out with the EmbeddedJava platform. This platformcontains a Java Virtual Machine and a collection of configurable Java classes designedfor memory-constrained embedded devices. It is an application environment that runs ontop of an RTOS. The RTOS requirements include memory management and file support,but a file system, window system and network support are optional.

There are two sets of Java classes contained in the EmbeddedJava platform. The firsthave API’s derived from the core Java classes. The second set is made up of hardware-specific classes. Licensees will configure the EmbeddedJava platform by choosing theJava classes, native code and virtual machine options that fit their products’ needs.

For example, if a product needs dynamic class loading the configuration in this case willinclude a virtual machine that supports that feature. Or, if all of the applications for a

20

product are known at build time, the bytecode verifier can be removed from the virtualmachine.

A licensee uses the EmbeddedJava environment to create a single file, called a ROMlet,with all the necessary classes and native code. If the device needs to be modified this isdone with a patchlet, which contains necessary updates. [7]

8 Critical Analysis of Java Programming System

This section is based on the facts about the JVM provided in the sections given below andthe opinions about Java as a whole that one of the authors has developed after researchingJVM for this paper.

Most of the computer systems today are developed around a register-based architecture.By choosing a stack-based architecture for JVM, Java developers have sacrificedperformance of Java programs for the lofty goal of 100% portability. In effect, today,Java is neither 100% portable nor does it offer suitable performance for large commercialapplications. A better choice would have been to add a layer of abstraction to JVM forstack-based hardware architectures that would give the impression that the program isactually running on a register-based machine. This abstraction will make Java run sloweron machines with stack-based CPU’s (very few) and would have made Java programs runa little faster on large majority of register-based machine. Specialized hardware chips,developed so far, for running Java are designed around a register-based architecture. Thisregister-based chip executes instructions that were designed for a stack-based machine(JVM), in effect sacrificing some performance. A register-based instruction set for Javawould have been a better choice to begin with.

Sun also currently uses a mark-and-scan garbage collector in its implementation of JVM.In mark-and-scan type garbage collector concurrent execution of program and garbagecollection are not possible. It may have been a better choice to use a copy garbagecollector in JVM (Microsoft uses a copy garbage collector in their implementation). Acopy garbage collector, in JVM, would have ensured better performance. Since JavaVirtual Machine specification does not specify anything about garbage collection, a copycollector could replace mark-and-scan collector.

In my opinion, Java is a wonderful programming language. Java is an excellentprogramming language for programmers who are interested in developing platformindependent and secure programs that operate over the network. It can also not beconsidered as an interpreted language anymore. With the advent of Just-In-Time compilerbased JVM’s Java has become more of a compiled language then an interpreted one.With the advent of specialized hardware chips for running Java (such as picoJava), Javabytecodes can be even considered to be slightly similar to micrcode. However, aninterpreter is usually present in all implementation of JVM. Developing chips that arespecially designed to execute Java, in effect defeats the purpose of Java platformindependent language. Large commercial applications developed in Java may only

21

perform well on picoJava chips and not on other hardware architecture. This in effect, is astep in the direction in making Java a platform specific language.

So far I have mentioned some negative points of JVM. However, JVM also has its strongpoints. Java offers the possibility of developing platform independent and secureapplications for heterogeneous networked based environment. When C was developed,proponents of assembly language claimed that C would never be as fast as assemblyprograms. Some claimed that it is better to write programs in assembly language ratherthat in C. Assembly language is much closer to the hardware CPU of a computer and Cabstracts a programmer away from tasks such as manipulating registers on a machine. Ineffect, C made programs easy to write by abstracting away from details that aprogrammer had to deal with while coding in assembly. Hand coded assembly programsare usually faster than C programs although very few people code in assembly today.

Today, the common claim being made is that Java programs are slow and do not performwell as compared to platform specific C programs. Use of Java is also being discouragedby claims such as “platform specific code will always be faster than Java bytecodes nomatter how much optimization is added to JVM.” These claims are true however Javaabstracts away from specific platform. Java also offers excellent built-in securitymechanisms and support for deployment over a networked environment. In effect Javaprovides a set of abstractions that are highly useful for developing networked-based,platform-independent, secure application. As Internet becomes more and more importantand as the processing power of hardware chips increase over the next few years,performance lag associated with Java may become less of an issue. Debate about benefitsof bytecodes vs. platform specific code may become as redundant as debate aboutassembly code vs. C programming language.

9 Conclusion

The Java Virtual Machine is an abstract specification that can be implemented in avariety of ways. It is designed to support Java’s goals of platform independence, securityand network mobility. The execution engine of the machine can be implemented by aninterpreter, a just-in-time compiler or in hardware. The latter use, while sacrificing someplatform independence, makes the machine practical for embedded devices.

The developers of the Java Virtual Machine specification from Sun Microsystemspurposely left implementation details out. They state, “Implementation details that are notpart of the Java Virtual Machine’s specification would unnecessarily constrain thecreativity of implementors...” [3, p. 57] “Designers are encouraged to apply their talentsand creativity toward building ever-better Java Virtual Machines.” [9, p. 128]

22

10 References

1. David Clark, “HP Enters the Java Fray”, Computer, June, 1998, p. 19.

2. Markus Levy, “The Scoop on Java”, EDN, November 7, 1996, pp. 73-84.

3. Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Addison-Wesley, 1997.

4. Harlan McGhan and Mike O’Connor, “PicoJava: A Direct Execution Engine For JavaBytecode”, Computer, October, 1998, pp. 22-30.

5. Jon Meyer and Troy Downing, Java Virtual Machine, O’Reilly, 1997.

6. Kelvin Nilsen, “picoPERC: A Small-Footprint Dialect of Java”, Dr. Dobb’s Journal,March, 1998, pp. 50-54.

7. Sun Microsystems, Inc., “EmbeddedJava Technical Overview”,http://www.javasoft.com/products/embeddedjava/spec/eJavaTechinalOverview.html.

8. Peter Varhol, “Adapting Java for embedded systems”, Computer Design,October,1997, pp. 75-80.

9. Bill Venners, Inside the Java Virtual Machine, McGraw-Hill, 1998.

10. T. Cramer, R. Friedman, T. Miller, D. Seberger, R. Wilson, M. Wolczko, “CompilingJava Just in Time”, IEEE Micro, May/June 1997, pp. 36 – 43.

11. B. Venners, “How the Java virtual machine handles method invocation and return”,Java World (http://www.javaworld.com/javaworld/jw-06-1997/jw-06-hood.html),June 1997.

12. B. Venners, “Security and the class loader architecture”, Java World(http://www.javaworld.com/javaworld/jw-09-1997/jw-09-hood.html), September1997.

13. B. Venners, “Java’s security architecture”, Java World(http://www.javaworld.com/javaworld/jw-08-1997/jw-08-hood.html), August 1997.

14. B. Venners, “How the Java virtual machine performs thread synchronization”, JavaWorld (http://www.javaworld.com/javaworld/jw-07-1997/jw-07-hood.html), July1997.