Wen-mei Hwu Department of ECE University of Illinois

© 1999, Wen-mei Hwu, All Rights Reserved1

Java Virtual Machine: VM Architecture, Software Architecture,

Implementations, and Application Programming Interfaces

Wen-mei Hwu

Department of ECE

University of Illinois


Objective of the Course• In-depth understanding of unique

aspects of Java-based systems

– Benefit of Java language features for various applications

– Complexities of the Java Bytecode architecture

– Functionalities of the Java API and runtime


Outline

• Introduction

• Basic Bytecode Architecture

• Java Objects

• Java Runtime

• Java Core API

• Related Technologies

• Java Related Developments


Java Security

• Bytecode Level

– Disallows pointer manipulation

– Provides array bounds checking

– Checks for NULL references (pointers)

– Eliminates illegal type casting


Java Security

• API Level

– Prohibits untrusted code from accessing local disk, creating processes, connecting to other hosts, calling native code, etc.

– Authentication: verify that bytecode is from a trusted vendor


Java Portability/Mobility

• Bytecode Level

– Binary compatibility: abstracts machine architecture and compiler

– Standard module format and compact representation

– Dynamic linking and loading


Java Portability/Mobility

• API Level

– Operating system abstraction

– Consistent support for

• Threads

• I/O and Network interface

• Database Interface

• Graphical User interface


Development Environment

• Language features

– Automatic memory management

– Structured exception handling

– Object-oriented design


Development Environment

• Modular development and 3rd-party software components

– Standard, dynamically linked modules

– Packages (related class file naming)

• Avoid naming conflicts

• Control access between modules


Key Application Areas• Network-based devices

– Mobility - applet downloading and software agents

– Portability - code server has no knowledge of client platform

– Security - code cannot be trusted


Key Application Areas

• Distributed applications

– Common development environment across tiers

– Same code can run on all machines

– Software can be repartitioned as hardware/requirements change


Database Application Development

• Can safely extend server software with Java bytecode

– Traditional approach: may crash server or corrupt database

– Java worst case: query fails or ties-up resources


Database Application Development

• Removes barriers between client and server development (same language/tools on both platforms)

• Easy linkage with server code (no binary compatibility issues)

• Run server on multiple platforms/easy migration


Incorporating Object Data Types• Objects can be serialized and

delivered to client

• Same code can manipulate an object on both server and client

– Different situations may call for either approach

• Bytecode can be loaded directly from the database


Database Example• Each employee record contains a

Java address object

• Custom logic can be incorporated in methods of the Java class Address

– Example: Using just street and zip, the Address initialization method computes city and state to ensure consistent address


Database Example

• Database designers can exploit inheritance to handle address idiosyncrasies

– Subclasses of type US_Address and CanadianAddress

– A different Java method computes short zip code depending on type


Database ExampleInsert new rows using inheritance:INSERT INTO employees (id, name, address)

VALUES (1001, “Bill Clinton”,new US_Address (‘1600 Pennsylvania Ave’, ‘22042-1234’))

INSERT INTO employees (id, name, address)VALUES (1002, “Jim Carrey”,new CanadianAddress(‘75 John Street’,‘N2L 3X2’))


Database Example

• Query cities and short zip codes

– Method to calculate short zip code runs on server

SELECT name, address.city, address.shortZip() FROM employees


Database Example• Query an address

– Short zip method runs on clientSELECT name, address FROM employees

WHERE ID = ‘1001’INTO cust_name, cust_address

IF cust_address.state = “IL” THENPRINT “Local Customer:” + cust_name+ “ Zip:” + cust_address.shortZip()


Challenges Presented By Java

• Translation to native architecture

– Instruction set translation

– Stack based to register based conversion

– Dynamic Linking - delay translation or manage binary dependencies


Challenges Presented By Java• Barriers to optimization

– Run-time checks (null ptr/array bounds) and exception handling constrain code motion

– Heavily object-oriented code - unable to resolve calls/inline

– Dynamic loading inhibits analysis (code base extended at runtime)


Challenges Presented By Java

• Security features add overhead

– Overhead of run-time checking instructions (null ptr/array bounds)

– Additional code and control flow to protect resource access


Bytecode Architecture Overview

• Load-store stack architecture– All operands pushed on value stack

before use• Source operands are fetched from

stack and the result is pushed on• Equivalent to register file in load-

store architectures



• Extensive support for Java Language and Dynamic Linking

– Object manipulation instructions

– Method invocation instructions

– Exception handling support



• Opcode space– 202 assigned, 25 quick, 3 reserved

• Load-store stack architecture– avoid register file size assumption– smaller code size

• 73.3% of the assigned opcodes are a single byte


Stack Computation ModelExample: add

Stack operation

push Apush B

add

Translated code

push Apush B

r2 pop(B)r1 pop(A)r3 r1+r2

push r3


Bytecode Modules (Class Files)• Java language compiler produces

separate module (class file) for each class defined in program

• All references across classes (and most within a class) – compiled as symbolic references – stored in a data structure inside

class file ( constant pool)


Bytecode Modules (Class Files)

• Bytecode with operands (27.7% of total assigned opcodes)– typically indexes into the

constant pool or local variable table


Bytecode operands• As VM executes a method its stack

frame holds a pointer to the constant pool of the method’s class

• When constant pool entry is first referenced by an instruction, the Java VM resolves the symbolic link


Simple exampleInvokevirtual 0x0005

Constant pool

...

...Stack frame

...5 Method ref

class ref

Name & type

“add”

‘(‘ ‘I’ ‘I’ ‘)’ ‘I’

8

a

d

11

...

...

...

...

Constant Pool


Bytecode operation types

• Stack Manipulations

– push, pop, duplicate, swap

• Local Variable accessing

– load, store

• Arrays

– create, store, retrieve


Bytecode operation types

• Objects

– create, access, set

• Arithmetic and Type Conversion

– add, subtract, multiply, divide, shift, AND, OR, XOR


Bytecode operation types• Control Flow and Exceptions

– conditional, unconditional, goto, local returns, tables, throws

• Method Calls and Returns– virtual, special, static, interface,

returns


• Patented by Sun• Interpreter based runtime optimization• Not part of VM spec, never appear in

class files• Patched over normal instructions at

runtime the first time they are executed

Quick Opcodes


Quick Opcodes

• When a constant pool entry is resolved, the symbolic is reference replaced with direct reference

• Quick opcode signifies constant pool entry already contains a direct reference to target, and VM does not have to perform certain checks


Java Objects Outline

• Classes and Interfaces

• Polymorphism and Dynamic Method Resolution

• Method Tables

• Bytecode Ops for Method Invocation

• Bytecode Ops for Object Manipulation


Language Terms

• Class: Data structure and associated functions to manipulate the data

• Object: An instance of a class (Object creation=Class instantiation)

• Method: Behavior associated with a class (function to manipulate object)

• Field: Individual elements of data defined by a class (object state)


Language Terms

• Polymorphism: Objects of different classes can be passed to the same client code. When the client code invokes a method on the object, the code executed depends on the object’s run-time class (requires dynamic method resolution, or late binding)


Basic Java Types• Primitive Types

– byte, short, int, long, char, float, double, boolean

– range of values for each type constant across platforms

• Reference Types (non-primitive)– Declare pointers to objects on the

Java Heap


Reference Types• Java language requires that each

reference variable has a declared type (statically typed)

• At runtime a reference may be assigned to different types of objects

• If a type-cast is potentially unsafe, compiler inserts run-time checks to insure type “compatibility”


Reference Types

• Interface: Set of guaranteed method declarations without any implementation

• Class: Set of guaranteed methods and fields including method implementation

• Only classes can be instantiated (objects always belong to a class)


Class Hierarchy• A class may extend one other class,

its superclass. A class inherits the fields and methods of its superclass including their implementation.

• A class may implement multiple interfaces, and must provide code for all methods guaranteed by those interfaces.


Extending Classes: Method Overriding

• A subclass contains both the methods “inherited” from its superclass and any new methods defined in the class

• A subclass may override a method in its superclass by redefining the method with same name, parameter types and return type


Abstract Classes• A class may defer implementing a

method by declaring it abstract

• A class with abstract methods cannot be instantiated

• Any non-abstract subclass that has an abstract class ancestor must provide the implementation for the ancestor’s abstract methods


Inheritance Hierarchy

• A class has only one superclass, but may have many ancestors

• Implementation of a single class can then be treated as multiple interfaces

Printer

LaserPrinter

OfficeMatePlus

FaxMachineCopier

Class

Interface

Extends

Implements

DotMatrix


Class/Interface Definition Example// Defer Printer implementationabstract class Printer { abstract void print(); }

// Override Printer.print()class DotMatrix extends

Printer void print() { // dot matrix printer code ... }}

// Override Printer.print()class LaserPrinter extends

Printer { void print() { // laser printer code ... }}

// Interfaces contain no codeinterface Copier { void makeCopies();}

interface FaxMachine { void sendFax();}

// Provide code for Copier and// FaxMachine interfaces// Inherit code from LaserPrinterclass OfficeMatePlus extends LaserPrinter implements Copier, FaxMachine { void makeCopies() { // code to make copies ... } void sendFax() { // code to send a fax ... }}


Dynamic Method Resolution• Dynamic resolution ensures that

the correct code will be invoked based on the object’s runtime class

• Interface Calls

– If reference type is an interface, method resolution locates the method’s implementation based on the object’s runtime class


Dynamic Method Resolution

• Virtual Calls

– If the reference type is a class, method resolution must determine which implementation to use - the object’s runtime class may override a method defined in a base class


Revisiting Class/Interface Example// Can use three types of machinesclass TrainedEmployee { void PrintDocument(

Printer p) { p.print(); // Virtual call } void replicateDocument(

Copier c) { // Interface call c.makeCopies(); } void faxDocument(

FaxMachine f) { // Interface call f.sendFax(); }}

// More office equipment

class QuickCopier implements Copier { public void makeCopies() { … }}

class EasyFaximplements FaxMachine { public void sendFax() { … }}


Revisiting Class/Interface Example// Create a new TrainedEmployeeTrainedEmployee e = new

TrainedEmployee();

// Create office equipment objectsDotMatrix dm = new

DotMatrix();QuickCopier qc = new

QuickCopier();EasyFax ef = new

EasyFax();

// TrainedEmployee can use all// three machinese.printDocument(dm);e.replicateDocument(qc);e.faxDocument(ef);

// Upgrade to the OfficeMatePlusOfficeMatePlus o = new OfficeMatePlus();

// Trained employee can do // everything with one machine// by using different interfaces// depending on the situatione.printDocument(o);e.replicateDocument(o);e.faxDocument(o);

// Polymorphism means you// don’t have to retrain your // employee


Vendor CodeClient Code - Evolves

Library Routine

Iterates through the

data structure.

Draws each shape in the collection.

Queue

Binary Tree

Hash Table

No need to recompile

Tree_Iterator

Queue_Iterator

Table_Iterator

Iterator

(Interface)

Stores a collection of shapes in custom

data structure

Passes the structure to Library Routine

Real-World Example• Client code has collection of shapes that

must be drawn by Vendor code


Method Tables• For dynamic method resolution, every

class maintains a table containing an entry for each non-static method

• An object reference points to its instance data on the Java Heap; in addition to instance fields, this data also contains a pointer to the method table for the object’s run-time class


Method Tables• Each entry in the method table points

to (depending on implementation):

– A method descriptor including the signature, access specifiers, and bytecode instructions

– An entry point into native code capable of invoking the method (the method descriptor is also available)


Method Area

Method Tables Example

print

Method Table forOfficeMate Class

Java Heap

copy

fax Code forOfficeMate

Code forLaserPrinter

Java Stack

OfficeMate object

Reference to OfficeMate object

method table ptr.

Fields


Constructing Method Tables

• Single inheritance allows methods from an ancestor class to occur at the same offset in method tables of all descendant classes

– Append methods to the table for each subclass so that superclass methods always precede the subclass methods


Constructing Method Tables

• Methods used to implement an interface might not occur at the same offset across method tables

• Classes that implement an interface may have no relationship in the linear inheritance hierarchy (different superclasses have different number of methods)


Method Tables

print

OfficeMate

copy

fax

Code forOfficeMate

Code forLaserPrinter

Code forEasyFax

print

LaserPrinter

fax

EasyFax

print

DotMatrix

Code forDotMatrix

Methods implementing abstract class Printer

Methods implementing interface FaxMachine

... ... ... ...


Runtime Method Resolution with Compiled Code

• Resolved Interface Call

– Although method offset constant within interface, interface offset may vary within method table

– Requires an extra “helper” function to locate a pointer to the interface


Runtime Method Resolution with Compiled Code

r1 mem[object_reference]Virtual Call

r2 mem[r1+Table_Off_In_Object]call [r2 + Method_Off_In_Table]

Interface Call

push r1

push InterfaceID

call resolveInterfaceOffset

(r2 result)call [r2 + Meth_Off_In_Interface]

Load object ref

Load ptr to meth tbl

Indirect call to virtual method

Object Ref (Param1)

Intrface ID (Param2)

Search Method Tbl

Offset of interface

Indirect call to interface method


Static Optimization forInterface Calls

• Compiler can place interface methods at a constant offset across classes by inserting holes in the method tables

• Compiler must have advance access to every class potentially loaded

– No dynamic linking


Problems with Virtual Calls• Call Overhead: Virtual Calls

require at least a memory load followed by an indirect call

• Prevents ILP

– Current branch prediction does not work well on indirect calls

– Unable to inline or perform interprocedural analysis


Optimizing Virtual Calls• Type Inference

– Class hierarchy analysis (prohibits dynamic loading)

– Type-aware dataflow analysis

• Type prediction

– Based on profile information

– Need mechanism to recover from incorrect prediction


Check Cast Details• Inserted by compiler at explicit casts

to verify that the type cast is safe:

– Interfaces must be implemented by the object’s runtime class

– Classes must be the same as or an ancestor of object’s runtime class

• If object reference cannot be cast to specified type, VM throws exception


Instance Of Details• Used when programmer requests

runtime type identification with the “instanceof” language keyword

• Compare the object’s runtime class to a specified type

• Uses same rules as CheckCast

• Returns ZERO on failure, ONE on success


CheckCast/InstanceOf Examplepublic class Housing { Vector kennel = new Vector(); Vector natural_habitat = new Vector(); void houseAnimals(Enumeration homeless) { while (homeless.hasMoreElements()) { // Enumeration returns an element of type Object // Compiler must insert CheckCast bytecode here Animal a = (Animal) homeless.nextElement(); // Compiler must insert InstanceOf bytecode here if (a instanceof Dog) kennel.addElement(a); else natural_habitat.addElement(a); } }}


Java Runtime Support Outline• Execution Models• Verification• Dynamic Linking• Dynamic Extension/Loading• Garbage Collection• Exception Handling


Java Runtime Environment (JRE)

beans

sqltextrmi

security ioawt

net util lang

Java VirtualMachine

Open VMS

Java Core API

JavaOS Win NTMacSolarisWin 95/98

UnixWareIRIXHP-UXAIX

OS/2 OthersUXP/DSRISC OSOS/390


Java Runtime Overview

Java Source

Javacompiler

Bytecode(.class)

ClassLoader

Bytecodeverifier

ConstantPool

Interpreter JIT

Memory Manager

SecurityManager

Services GUI

Operating System

Hardware

Execution Engine

Java VM


Basic elements of the JVM• Bytecode execution

– Interpreter– JIT– Static Compilation– Java Processors


Basic elements of the JVM• Memory management

– garbage collection• Class loading• Class file and bytecode verification


JIT Compiler/VM Interface

• Compilation Unit for the JIT is a single method – JIT may request additional

methods for inlining• VM decides which methods to

compile


JIT Compiler/VM Interface

• JIT makes assumptions about the runtime environment such as:– Code and Data blocks allocated

through the VM will stay in place– Every object contains the

reference to the class’s method-pointer table


Anatomy of a JIT

Memory

Bytecodeimporter

IR Optimizer

CodeGenerator

Linker

BytecodeExecutor

--Runtime

Controller

Java Virtual Machine

1 2 3

45

6

7

8

9

JIT


Anatomy of a JIT

1 Runtime controller makes JIT request– passes pointer to memory location of

bytecode2 Bytecode importer obtains bytecode

and converts it to internal representation (IR)

3 The internal representation is then optimized


Anatomy of a JIT4 Code generator generates native code

from IR

5 Code generator requests needed memory from runtime controller – runtime controller passes back

pointer to requested memory6 Linker performs traditional linker

functions


Anatomy of a JIT7 Linker places native code in memory at

location specified runtime controller8 Linker provides controller information

concerning native code to the runtime controller

9 Runtime controller responsible for memory management


HotSpot Summary• JIT with C-quality code generator

– much faster byetcode execution– JIT optimizes the small percentage

of the code that accounts for the majority of the execution time

– allows more time for more aggressive optimizations

• Adaptive optimization and aggressive inlining– uses runtime profiling data


HotSpot Summary• Garbage Collection

– exact generational collector– Non-disruptive

• Faster thread synchronization– reduction of overhead on

allocation and deallocation of thread spaces


Verification

• Occurs when VM loads a class file, prior to linking the class

• Checks for valid class file structure and valid bytecode

• Relieves the VM from performing these checks at runtime


Verification• VM rules for properly formed

bytecode– Valid Opcodes– Operand stack always contains

the same number and type of items no matter which execution path is taken


Dynamic Linking

• Recall: All references are compiled as symbolic references and stored in a data structure inside the class file called the constant pool

• Each class can be separately developed and recompiled without recompiling any other classes

• Release-To-Release-Binary-compatibility is guaranteed


Dynamic Linking

• VM may throw a linkage exceptions at runtime when a referenced class, method, or field cannot be located or has conflicting access specifiers– Not thrown until bytecode that

indexes the reference is actively used


Static Resolution Example• To resolve static field reference the VM

checks:– referenced class exists and this class

has permission to access it– named field exists in referenced class,

has expected type, is static not instance, and this class has permission to access the field

• Similar checks occur for class references (new, checkcast, etc.) and method references (invoke…)


Dynamic Extension/Loading• Load class at runtime that

compiler does not have access to at compile-time

• Program may access a new class without providing explicit reference to it in the constant pool

• Accomplished by first providing class loader with the name of the new class


Dynamic Extension/Loading• Second, instructing the newly loaded

class to create a new instance, • Third, then either:

– casting the new instance to a known interface/base class

– using introspection to query and dynamically access its fields and methods


Dynamic Loading Example

interface QueryDriver { String processQuery(String command);}

// This class is unknown at compile timeclass DynamicDriver implements QueryDriver { public String processQuery(String command)

{ … }}


class DynamicLoader { void run(String driver_name) throws ClassNotFoundException, IllegalAccessException, InstantiationException { // Instruct class loader to create named class Class driver_class = Class.forName(driver_name); try {

// Create a new instance of the driver// class, cast to QueryDriver

QueryDriver driver = (QueryDriver) driver_class.newInstance();

String command = getInput(); // If cast succeeded, driver implements processQuery String result = driver.processQuery(command); } catch(ClassCastException e) { …

// Invalid Driver } }}


Custom Classloaders• Developers can extend the built-in class

loader architecture to load bytecode from alternative sources:– Download across the network– Query from a database– Extract from binary formats other

than standard class file– Compile/compute bytecode on the fly


Custom Classloaders• Example: Applets

– Web browser starts an appletviewer Java program in a frame

– Appletviewer dynamically loads class specified in HTML tag from HTTP host

– Appletviewer creates new instance of class, casts it to base Applet class, and invokes init() and start() methods


Support for Dynamic Loading in Static Compilers

• Executable image will not contain all code

• Typical approaches– Require developer to “freeze”

application (No Support)– Add dynamic loader/linker code

and access to a JVM



• Optimization tradeoffs

– Unable to perform complete class hierarchy analysis

• If compiler knows that class has not been extended it can convert virtual calls to direct calls allowing inlining and interprocedural optimizations



• Optimization tradeoffs

– Reduces ability to optimize interface calls: can’t establish constant method table offset


Garbage CollectionType I: Reference counting

Root Set

1

.

.

.

.

Heap Space A:

B:

C:

X:

D: E:

H:G:

F:

2 1

2

1

1

1

11


Garbage CollectionType I: Reference counting (cont.)

Root Set

1

.

.

.

.

Heap Space A:

B:

C:

X:

D: E:

H:G:

F:

2 1

1

1

1

1

11

A-B-C forma circle


Garbage CollectionType II: Marking & Sweeping

Root Set

.

.

.

.

.

.

Heap Space A:

B:

C:

X:

D: E:

H:G:F:

Mark Bits-- -A -- -G-F C- -- --X- -- B- ---- F- -- HD


Garbage CollectionType III: Copying

Root Set

From Space

A:

C:B:

D:

To Space

A B C DA B D D

E:


Garbage CollectionType III: Copying (cont.)

GarbageLive object

time

heapallocated size


G.C. Optimizations

• G.C. Prevention– heap objects live analysis

• insert explicit “free”• allocate local objects from stack

• G.C. Efficiency (tradeoff: heap access indirection overhead)


G.C. Optimizations

• Minimize heap fragmentation– heap allocation policy (first fit, best

fit, etc.)– death time discrimination

• appears correlated to birth time and obj. type

• Advanced considerations (cache performance, etc.)


• Divide heap into generations• When current generation fills up,

perform copying collection to move the objects to the next older generation (recursive)

Garbage CollectionType IV: Generational


• Short-lived objects quickly freed without recopying long-lived objects– Especially beneficial if long-

lived=large and short-lived=small• Only need to scan root-set and

generations newer than one being collected



• If objects in older generations point to newer objects– Track these references in separate

data structure– Use write-barrier when writing to an

older generation (may be significant overhead for storing references)



Garbage CollectionType IV: Generational (cont.)

GarbageLive object

time

size

First Generation

Second Generation

Third Generation

Recursive collect


Exception Handling

• An exception is thrown at a point in the code where some exceptional condition prevents continuation of the current method or scope

• Control flow breaks and resumes at the nearest exception handler registered to catch this type of exception


Exception Handling• While the type of exception thrown

selects the handler, information about the error is stored inside the exception– exception is an object in Java

• All exception classes derived from Throwable which supports the methods:– String getMessage()– void printStackTrace()


VM vs. User Exceptions• VM thrown exceptions can

implicitly occur almost anywhere– Derived from Error, need system

attention• Virtual Machine Errors

(OutOfMemory, etc.)• Dynamic Linking

(ClassFormatError, etc.)


VM vs. User Exceptions• VM thrown exceptions

– Derived from RuntimeException, can be handled by the user• Array Bounds Checking• Null Pointer Checking• Explicit Type Casting• Security Checks


VM vs. User Exceptions• User thrown exceptions must be

explicitly declared and thrown with a throw statement


Why use Exception Handling?

• Insufficient information to deal with an error in the current context - the exception to be handled in a “higher” context

• Intermediate code is easier to read and write because it is not complicated with error checking


Why use Exception Handling?

• No need to check return type for error condition at every method call

• Catches unforeseen programming bugs inside code that the compiler could not detect... especially useful if the bug is hidden inside library code


Java Exceptions Example Codeclass DatabaseException extends Exception {}class IndexException extends DatabaseException {}class ReadException extends DatabaseException {}class VendorDatabase { int getOffsetForID(int id) throws IndexException

{...} String readName(int offs) throws

RecordReadException {...} // Let higher context decide what to do about

// different exceptions String getNameForID(int id) throws

IndexException, ReadException { int offs = getOffsetForID(id); return readName(offs); }}


// User Code: display name in box// or display appropriate errorvoid showRecord(Dialog msgbox, VendorDatabase data, int id) { String message; try { message = data.getNameForID(id); } // Don’t care which type of database exception // occurred, but want to handle it nicely catch (DatabaseException e) { message = "Data unavailable:” + e.getMessage(); } msgbox.setTitle(message); msgbox.show();}


Typical C Error Handling// Must change function declarations// to handle errors (return error code)int getOffsetForID(int id, int *offset){ ... // Difficult to provide detailed information // to a higher context if (errorcondition) return -1; else return 0;}// Alternative: cause terminationchar *readName(int offs) { ... if (errorcondition) { perror(“Bad database format”); exit(-1); } ...}


Typical C Error Handlingint getNameForID(int id, char **str){ int result

// Error checking complicates all intermediate layers if (getOffsetForID(id, &result) != 0) return -1;

// User code now has no way to handle errors // inside readName library function or to provide a // different reporting mechanism (other than perror) *str = readName(offs); return 0;}


Finally Clause• Code inside a finally block is executed

regardless of how control flow exits a try block

• Useful for cleanup code that must run even if an exception has occurred

• Compiler implements with jsr/ret instructions (unlike invoke/return, does not create stack frame)


Finally Clause// User Code: read ID from file, return namevoid NameFromFile(UserFile file, VendorDatabase data) throws DatabaseException, IOException{ String name; file.open(); try { int id = file.readInt(); name = data.getNameForID(id); } // Don’t catch any exceptions here // Allow a higher context to handle them finally { // Cleanup code always needs to run file.close(); } return name;}


Exception Tables

• Compiler attaches an exception table to each method with a try block

• An entry for each exception handler contains:

from first bytecode op inside try blockto last bytecode op inside try blocktarget entry point of exception handlertype class of exceptions handled


Exception Tables• When exception occurs the VM checks

– If pc between from and to, exception type matches type, then VM sets pc to target and resumes

– If no exception handler matches, VM pops method frame, sets pc to the return address, and continues checking with exception table for the caller method


Finally/Exception Tables

Java method

void run() throws Exception { int i = 0; try { i++; } finally { i++; } // i always equals 2 here}


Compiled BytecodeMethod void run() 0 iconst_0 1 istore_1 // initialize local var 2 iinc 1 1 // inc local var 5 jsr 15 // execute finally 8 return // Compiler inserts default exception handler 9 astore_2 10 jsr 15 // execute finally 13 aload_2 14 athrow // rethrow exception // finally clause as subroutine 15 astore_3 // store return addr in l.v. #3 16 iinc 1 1 19 ret 3 // return addr in l.v. #3Exception table: from to target type 2 5 9 any

Try block


Exception handling considerations

• Two types– catastrophic: program terminates– non-catastrophic: execution

continues after code in catch block is executed


Exception handling considerations

catastrophic non-catastrophic

system user defined

state lost state resetstate maintained

Types of exceptions

Types of behavior

Effectsonprogram/machinestate Restricts code motion


Exception Handler Considerations

7

9

8

6

4

5 14

def LV[1] use LV[1]

use LV[1]

use LV[1]LV[2] = 1

10

LV[2] =10/0

LV[2] alive later

Exception handler

4’Try-block Catch-block


Java Core API Overview• Set of runtime libraries providing a

standard way to access system resources

• Notable API features– Threads– Serialization– Reflection/Introspection– RMI


Some standard API groups

– AWT- graphical user interfaces– IO - standard IO– LANG - basic language support– NET - network communications– UTIL - data structure and

collections


Java Threads• Thread class abstracts underlying OS

to provide standard interface for multi-threaded execution

• Synchronization

– Each object “owns” a single monitor (lock)

– Monitor can be used as in two ways: mutual exclusion or cooperation


Mutual Exclusion

• Synchronized keyword: defines critical sections that may only be accessed by one thread at a time

• Compiler inserts monitorenter and monitorexit bytecode instructions

• Methods declared synchronized do not require additional bytecode instructions


Thread Cooperation• wait() method - relinquish monitor

but remain in the “wait set”

• notify() method - resurrect a thread in the “wait set”

• After notifying thread releases monitor, notified thread leaves “wait set”, acquires monitor, and begins executing (Example: I/O buffer)


Cooperative Synchronization

object

thread1

count=1

thread2

thread3

thread4

monitor

wait set

object.notify()

notifies next waiting thread (thread2)

object.wait()

relinquishes object’s monitor and enters the wait set allowing thread2 to acquire the monitor

heap space(before)

object

thread2

count=1

thread3

thread4

thread1

monitor

wait set

heap space(after)

(blocked) (blocked)

(runnable)(runnable)

Thread1 executes:


Serialization

• Serialization writes the complete state of an object to a stream

– Except transient or static fields or non-serializable objects

– May entail graph traversal to cover other referenced objects (web of objects)


Serialization Uses

• Persistent objects - let objects “stick around” between program invocations

– Archives and Databases

– Checkpoint/Restart to limit data loss or for job-scheduling


Serialization Uses

• Transfer objects - for communication or replication

– RMI: move object data between client and server (marshalling)

– Beans: send initialized (customized) objects instead of class files


Program Instance #2Program Instance #1

File/Network Stream

Serialization Diagram


Reflection API

• Support for querying the internals of a classConstructor[] Class.getConstructors()

Constructor Class.getConstructor(Class[] paramTypes)

Method[] Class.getMethods()

Method Class.getMethod(String name, Class[] paramTypes)

Field[] Class.getFields()

Field Class.getField(String name)


Reflection API

• Support for dynamically invoking the class members

Object Field.get (Object obj)

void Field.set (Object obj, Object value)

Object Method.invoke(Object obj, Object[] args)

Object Constructor.newInstance(Object[] initargs)


Reflection API

• Why Reflection?

– Allow integration with Java objects determined at runtime (don’t need to know interface at compile time)

– Facilitate component software (JavaBeans)


Using Reflectioninterface Toy {}

class Frisbee

implements Toy {}

class Stick

implements Toy {}

class Dog {

public void

fetch(Toy toy) {...}

public void

chew(Toy toy) {...}

}

Normally, programmer hard-codes the name of the method:

...Dog corky = new Dog();corky.fetch(new Stick());corky.chew(new Frisbee());...


Using ReflectionWith reflection, method

names can be runtime parameters:

void playWithDog(Dog dog, String game_name,

Toy toy) {

Method game = Dog.class.

getMethod(game_name, Class[] {Toy.class} );

game.invoke(dog, toy);

}

...Dog corky = new Dog();playWithDog(corky, “fetch”, new Stick());playWithDog(corky, “chew”, new Frisbee());...


JavaBeans• Build customizable software

components in Java

• A component (Java class) can simply use a standard naming convention to “publish” its interface as a JavaBean

• Standard naming defines a bean’s properties, methods, and events


JavaBeans• Properties: Allow configuration of

the internal state of the bean

• Methods: Other components can invoke services provided by bean

• Events: Other components can receive notification if something happens in the bean (e.g. state transition)


Visual Development

• Application builder tool allows construction of application by customizing and connecting beans

• Import 3rd party beans

• Visually present bean properties for customization (e.g. size, color, title, timing delay)


Visual Development

• Allow connecting bean events to methods of other beans (e.g. Button.mouseClickEvent -> Animation.start()

• Save custom state as pre-initialized beans using serialization

• Looks like standard Java program to end user


Visual Development Example

• Creating a graphical interface for database queries

• Developer adds a Button and Query Viewer bean to the canvas

• Developer connects the Button’s clicked event to the Query Viewer’s run method


Visual Development Example

Query Viewer

ButtonRegister an

event listener with Button’s clicked Event (Initialization)

Mouse click on Button invokes

registered event listeners.

The event listener calls

Query Viewer’s run methodData Source

Query Command

# Rows to Fetch

properties

registered

event listeners

Run QueryRun Query


RMI - Remote Method Invocation• Send messages to Java objects

running on another machine (distributed objects)

• Similar to RPC, but object-based

• RMI can also load code from server

• On each machine, a communication object must take the place of the remote object


RMI Communication objects• Client side: stub object takes place

of server object (proxy)

• Server side: skeleton object receives requests from proxy stub and delivers them to intended object

• Interfaces create abstraction between communication object and actual remote object


Using RMI

• Each server object is registered with a local registry and must provide a unique name

• The RMI compiler automatically produces stub and skeleton classes for communications


Server MachineClient Machine

Server VM

RMI Diagram

Client VM

Client

Object

Proxy

Stub

Skeleton

Object

Server

Object

Network

Local

RegistryUnique Name


RMI Considerations• Arguments must be marshaled

(converted to binary stream to send across the network)

• Object passed must implement Serializable (pass entire object) or Remote (pass a remote reference)

• Reference counting tracks live references across virtual machines


Related technologies• COM

– Microsoft Component Object Model

– Packages objects as interoperable “components”

• provide well defined services

• visible to independently developed applications

– Cross language support


Related technologies• DCOM

– Extension of COM to allow distributed components

– Alternative to RMI• CORBA

– OMG spec. for cross-language distributed object infrastructure

– Alternative to RMI and DCOM


COM Details• MIDL describes COM classes,

interfaces, and methods

• COM provides a binary specification for representing the objects at runtime

– Standard method table layout

– Standard data format for parameters

• Implemented in any language that can produce this layout (C++, VisualBasic)


COM Details• Components can reside in

separate binaries (DLL/EXE)

• Dynamic linking allows independent component evolution

• Components registered by the OS

– GUID and name identifies type

– Type library available to all applications


COM at the Language Level

• COM objects expose only interfaces (no data or implementation exposed)

• COM classes can implement multiple interfaces (like Java). Howeverm client code only retrieves a pointer to the interface, never the class itself


COM at the Language Level• Reference object model (like Java),

programmer passes object handles

• COM manages object lifetime (like Java), uses reference counting

• All interfaces derived from IUnknown

– Safe casting to more sophisticated interfaces (QueryInterface)

– Reference Counting (AddRef/Release)


COM Interfaces (Runtime Spec.)

• COM maintains separate method table pointers for each interface

• Subsequent interface calls are quick by retaining interface pointer

• Only one interface used at a time, but can recast to multiple interfaces

• No direct field access


COM Interfaces (Runtime Spec.)Each interface structure contains:• pointer to its offset in the method table• pointer back to the original object for

internal field access and “recasting”

COM Handle fields

Interface AInterface AMethods

..

COM Object COM ClassMethod Table

Interface B

Interface B Ptr.

...Interface BMethods

..


Java/COM Integration• COM interfaces almost identical to

Java interfaces at language level

• Microsoft VM provides bi-directional Java-COM compatibility

– Java objects can be exposed as COM objects

– COM objects seen as regular Java objects to Java code


Java/COM Integration

Visual BasicProgram

COMInterface

RegularCOM Object

MSJAVA.DLL

JavaProgram

Java Class w/COM Attribute

(wrapper)Init VM,

Create instanceof Java COM obj.

RegularJava

Classes

COM Object

COMInterface


Java vs. COM

• Runtime binary standard– COM - Defines method table layout

and standard data types– Java - Classes distributed in

standard format then dynamically linked (each VM may determine runtime memory layout independently)


Java vs. COM• Published type information

– COM - Type library in system registry, GUID as identifier.

– Java - Class files contain complete interface definition. Uses system’s “CLASSPATH” or URL to locate files. Internet naming conventions avoid conflicts.


DCOM Overview• Distributed COM objects

• DCOM object can replace a COM object without recompiling code

• Remote invocation similar to RMI: use stubs and skeletons to abstract network communications

• Integrates with Java via COM integration


DCOM Architecture• OS maintained type library

analogous to RMI registry• To establish communications:

– Ask the remote server to create a new object for a COM type

– Receive an interface pointer representing the new object

• Specific objects assigned a moniker


DCOM Architecture Example

Microsoft VMMicrosoft VM

DCOM

Server

Control

Manager

DCOM

Server

Control

Manager

Remote System with DCOM support

Remote System with DCOM support

S

C

M

S

C

M

anonymousobject

anonymousobject

COM skeleton

COM skeleton

COM proxy

COM proxy

Java client B

Java client A


CORBA Overview

• Standard for distributed, language-independent component interoperability (designed to many types of distributed objects)

• Interface Definition Language (IDL) language neutral way to specify data types, attributes, operations

• IDL stored in Interface Repository


CORBA Overview

• Object Request Broker (ORB) manages the interface repository, provides the communications protocol for objects, and performs reference counting

• Related standard: Internet Inter-ORB Protocol (IIOP) to communicate between ORBS


CORBA Comparison• Like RMI and DCOM, stubs/skeletons

abstract network communications

• Similar in scope to DCOM

• Some basic differences:

– CORBA creates unique object ID, DCOM uses monikers to reconnect

– CORBA requires 3rd party ORB, many alternatives


CORBA vs. RMI

• CORBA allows integration of Java with other language code without having a Java VM present on the remote machine

• CORBA requires 3rd party ORB (similar to RMI’s local Registry)

• CORBA requires IDL definitions (can be automated)


C++

ORB

C++

ORB

Java VMJava VM

Java

ORB

Java

ORB

Remote System (C++ code)

Remote System (C++ code)IIOP

CORBA Architecture

IR IR

Java client A

Java client A

client stub

client stub

server skeleton

shared object


Java Developments

• Personal Java

• Embedded Java

• Java Card

• JavaOS


Personal Java

• Target: Network applications on personal consumer devices (e.g. set-top boxes/smart phones)

• Problem: Core Java API designed to run on desktop machines

• Solution: Personal Java API - Redefines Core Java API, omitting some features, modifying others.


Personal Java API• Features can be optionally supported

– Example: printing, math functions– Throws exception if unsupported

• Redefines java.awt (smaller)– Graphics and windowing support– Supports low-resolution displays– Supports alternate input devices


Personal Java Machine Requirements

• Processor: 32 bit , 50+ MHz

• ROM: 2 MB, RAM: 512 KB-1MB

• Network connection

• Keyboard or alternate input

• Requirements do not include space for application code and data

• Runs on major real-time OS’s


Embedded Java• Provides tools to extract bytecode

needed for embedded application• Compresses bytecode and places

it in the data segment of a C file• C file compiled as usual for

embedded device• Links with scaled-down VM code

which executes the bytecode


ApplicationClasses

ApplicationClasses

Embedded JavaClasses

Embedded JavaClasses

HardwareClasses

HardwareClasses

filter and compact code

ROMjava.c

StaticData

StaticData

compact data

staticData.cDeveloper

Embedded Java

Vendor

Native compiler

nativelinker

ROMletROMlet

staticData.oROMjava.o

nativemethodsnative

methods

VirtualMachineVirtual

Machine

OS imageOS image

Embedded Java Components


Personal vs. Embedded Java• Share many of the same

development tools• Both upward compatible with

standard Java• Personal Java - Support multiple

Java apps with certain features• Embedded - Tune system for one

Java application


Personal Java Key Points

• Like standard Java, designed to run arbitrary applets downloaded across a network (runs most general-purpose applets)

• Provides a well-defined subset of API features; throws exception if the applications requests an unsupported operation


Embedded Java Key Points

• Minimal code necessary for application support determined at compile-time prior to installing executable image

• Virtually all API features available for developers, but only features required by a specific application are installed on the device


JavaCard Goals

• Allow “smart card” developers to write code in Java

• Device requirements

– 16K of ROM

– 8K of EEPROM (non-volatile)

– 256 bytes of RAM


JavaCard Solution• Provide a scaled down VM

implementation

• Provide minimal subset of Java API (Basic Object and Exception classes)

• Support a large subset of the Java language (no keywords for large data types and advanced features)


JavaCard VM• Minimal VM, no support for:

– Large primitive data types (float, double, long, and char)

– Dynamic class loading– Security manager– Threads and synchronization– Object cloning– Finalization (Specification does

not require Garbage Collection)


JavaCard Split VM

• Off-card

– Class loading, linking, resolution

– Verification

– Bytecode optimization and conversions

• On-card

– Bytecode execution


Java Card Applets

• Additional framework for card applets

– Communications protocol w/ terminal

– File system compatible w/ industry standard

– Cryptographic functions


Java Card Applets

• Installation:

– Native OS, Java Card VM, API class libraries, and some applets (optional) are burned into ROM

– Other JavaCard applets can be installed after card is issued


Java Card Considerations• Assume external power source

– Machine state must remain consistent with loss of power

– VM initialized at installation, runs throughout life of the card

– General objects stored in EEPROM

– Objects declared transient can reside in RAM


Java Card Considerations

• Memory space is limited

– Applets should create and initialize all necessary objects at installation to avoid hitting memory limit at runtime


JavaOS Features• Machines that only run Java

programs can bypass host OS

– Allows precise tuning for Java performance

– Minimal memory requirements

• Intended to scale across wide range of hardware platforms

• Portable drivers (written in Java)


JavaOS Architecture

• Native-Java abstraction at lowest possible level

– Memory Access Classes (Virtual Memory / IOPort / DMA Access)

– Interrupt Classes

– Java Platform Interface (JPI) to machine dependent microkernel


JavaOS Architecture Layers• Microkernel and Memory Manager

(native)• Device Drivers (mostly bytecode)• Java Virtual Machine (bytecode,

calls native system functions)• JavaOS Graphics and Windowing

systems (bytecode)• Full Java API (bytecode)


JavaOS Runtime

Core Java ClassesCore Java Classes

Java Language Classes

Java Language Classes

AWTClasses

AWTClasses

I/OClasses

I/OClasses

Java Virtual MachineJava Virtual Machine AWTSupport

AWTSupport

I/OSupport

I/OSupport

JavaOSDevice Drivers

JavaOSDevice Drivers

JavaOS Platform Interface

JavaOS MicrokernelJavaOS Microkernel

JavaOS Components


DisclaimerJava and all Java-based trademarks and

logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All other trademarks, registered trademarks and product names are property of their respective holders.

Product descriptions are based on the best information publicly available.


Java Programming

• Bruce Eckel. Thinking in Java. Prentice Hall, 1998. http://www.BruceEckel.com

• David Flanagan. Java in a Nutshell. O'Reilly, 1997.


Java Virtual Machine

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

• Jon Meyer and Troy Downing. Java Virtual Machine. O'Reilly, 1997.

• Bill Venners. Inside the Java Virtual Machine. McGraw-Hill, 1998.http://www.artima.com


Distributed Objects

• Robert Orfali and Dan Harkey. Client Server Programming with Java and Corba. Wiley, 1997.

• Roger Sessions. COM and DCOM: Microsoft's Vision for Distributed Objects. Wiley, 1998.

• "DCOM Architecture." White Paper. Microsoft Corp., 1998.


COM• Don Box. Essential COM. Addison-

Wesley, 1998.• Dale Rogerson, Inside COM,

Microsoft Press, 1997.• "The Component Object Model

Specification." Microsoft Corp.,draft version 0.9 edition, 1995.

• "Understanding the JAVA/COM Integration Model." Microsoft Interactive Developer, April 1997.


Static, Java to native compilers:• Supercede, Inc., Supercede,

www.supercede.com• Tower Technology Corporation,

TowerJ, www.twr.com• Symantec Corporation, VisualCafe,

www.symantec.com/domain/cafe/• Open Group Research Institute,

TurboJ, www.camb.opengroup.org /openitsol/turboj/


Other Products• Sybase, Inc., Adaptive Server and

Java, Whitepaper, www.sybase.com/adaptiveserver /whitepapers/java_wps.html

• Newmonics, Inc., Java support for real-time systems,www.newmonics.com


Java SpecificationsSun Microsystems, Inc.

• Embedded Java Specification, www.javasoft.com/products/embeddedjava/

• Java Card Specification, java.sun.com/products/javacard/

• JavaBeans, www.javasoft.com/beans/• JavaOS, www.sun.com/javaos/• Personal Java Specification,

www.javasoft.com/products/personaljava/• picoJaca Microprocessor core, www.sun.com

/microelectronics/whitepapers/wpr-0014-01/

Documents

Wen-mei Hwu Department of ECE University of Illinois