© 1999, Wen-mei Hwu, All Rights Reserved1
Java Virtual Machine: VM Architecture, Software Architecture,
Implementations, and Application Programming Interfaces
Wen-mei HwuDepartment of ECEUniversity of Illinois
© 1999, Wen-mei Hwu, All Rights Reserved2
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
© 1999, Wen-mei Hwu, All Rights Reserved3
Outline• Introduction• Basic Bytecode Architecture• Java Objects• Java Runtime• Java Core API• Related Technologies• Java Related Developments
© 1999, Wen-mei Hwu, All Rights Reserved4
Java Security• Bytecode Level
– Disallows pointer manipulation– Provides array bounds checking– Checks for NULL references
(pointers)– Eliminates illegal type casting
© 1999, Wen-mei Hwu, All Rights Reserved5
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
© 1999, Wen-mei Hwu, All Rights Reserved6
Java Portability/Mobility• Bytecode Level
– Binary compatibility: abstracts machine architecture and compiler
– Standard module format and compact representation
– Dynamic linking and loading
© 1999, Wen-mei Hwu, All Rights Reserved7
Java Portability/Mobility• API Level
– Operating system abstraction– Consistent support for
• Threads• I/O and Network interface• Database Interface• Graphical User interface
© 1999, Wen-mei Hwu, All Rights Reserved8
Development Environment
• Language features– Automatic memory management– Structured exception handling– Object-oriented design
© 1999, Wen-mei Hwu, All Rights Reserved9
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
© 1999, Wen-mei Hwu, All Rights Reserved10
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
© 1999, Wen-mei Hwu, All Rights Reserved11
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
© 1999, Wen-mei Hwu, All Rights Reserved12
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
© 1999, Wen-mei Hwu, All Rights Reserved13
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
© 1999, Wen-mei Hwu, All Rights Reserved14
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
© 1999, Wen-mei Hwu, All Rights Reserved15
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
© 1999, Wen-mei Hwu, All Rights Reserved16
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
© 1999, Wen-mei Hwu, All Rights Reserved17
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’))
© 1999, Wen-mei Hwu, All Rights Reserved18
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
© 1999, Wen-mei Hwu, All Rights Reserved19
Database Example• Query an address
– Short zip method runs on clientSELECT name, address FROM employeesWHERE ID = ‘1001’INTO cust_name, cust_addressIF cust_address.state = “IL” THENPRINT “Local Customer:” + cust_name+ “ Zip:” + cust_address.shortZip()
© 1999, Wen-mei Hwu, All Rights Reserved20
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
© 1999, Wen-mei Hwu, All Rights Reserved21
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)
© 1999, Wen-mei Hwu, All Rights Reserved22
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
© 1999, Wen-mei Hwu, All Rights Reserved23
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
© 1999, Wen-mei Hwu, All Rights Reserved24
Bytecode Architecture Overview• Extensive support for Java
Language and Dynamic Linking– Object manipulation instructions– Method invocation instructions– Exception handling support
© 1999, Wen-mei Hwu, All Rights Reserved25
Bytecode Architecture Overview• 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
© 1999, Wen-mei Hwu, All Rights Reserved26
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
© 1999, Wen-mei Hwu, All Rights Reserved27
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)
© 1999, Wen-mei Hwu, All Rights Reserved28
Bytecode Modules (Class Files)• Bytecode with operands (27.7% of
total assigned opcodes)– typically indexes into the
constant pool or local variable table
© 1999, Wen-mei Hwu, All Rights Reserved29
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
© 1999, Wen-mei Hwu, All Rights Reserved30
Simple exampleInvokevirtual 0x0005
Constant pool...
...Stack frame
...5 Method ref
class ref
Name & type
“add”
‘(‘ ‘I’ ‘I’ ‘)’ ‘I’
8
a
d
11
...
...
...
...
Constant Pool
© 1999, Wen-mei Hwu, All Rights Reserved31
Bytecode operation types• Stack Manipulations
– push, pop, duplicate, swap• Local Variable accessing
– load, store• Arrays
– create, store, retrieve
© 1999, Wen-mei Hwu, All Rights Reserved32
Bytecode operation types• Objects
– create, access, set• Arithmetic and Type Conversion
– add, subtract, multiply, divide, shift, AND, OR, XOR
© 1999, Wen-mei Hwu, All Rights Reserved33
Bytecode operation types• Control Flow and Exceptions
– conditional, unconditional, goto, local returns, tables, throws
• Method Calls and Returns– virtual, special, static, interface,
returns
© 1999, Wen-mei Hwu, All Rights Reserved34
• 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
© 1999, Wen-mei Hwu, All Rights Reserved35
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
© 1999, Wen-mei Hwu, All Rights Reserved36
Java Objects Outline• Classes and Interfaces• Polymorphism and Dynamic Method
Resolution• Method Tables• Bytecode Ops for Method Invocation• Bytecode Ops for Object
Manipulation
© 1999, Wen-mei Hwu, All Rights Reserved37
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)
© 1999, Wen-mei Hwu, All Rights Reserved38
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)
© 1999, Wen-mei Hwu, All Rights Reserved39
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
© 1999, Wen-mei Hwu, All Rights Reserved40
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”
© 1999, Wen-mei Hwu, All Rights Reserved41
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)
© 1999, Wen-mei Hwu, All Rights Reserved42
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.
© 1999, Wen-mei Hwu, All Rights Reserved43
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
© 1999, Wen-mei Hwu, All Rights Reserved44
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
© 1999, Wen-mei Hwu, All Rights Reserved45
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
ClassInterfaceExtendsImplements
DotMatrix
© 1999, Wen-mei Hwu, All Rights Reserved46
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 ... }}
© 1999, Wen-mei Hwu, All Rights Reserved47
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
© 1999, Wen-mei Hwu, All Rights Reserved48
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
© 1999, Wen-mei Hwu, All Rights Reserved49
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() { … }}
© 1999, Wen-mei Hwu, All Rights Reserved50
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
© 1999, Wen-mei Hwu, All Rights Reserved51
Vendor CodeClient Code - EvolvesLibrary 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
© 1999, Wen-mei Hwu, All Rights Reserved52
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
© 1999, Wen-mei Hwu, All Rights Reserved53
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)
© 1999, Wen-mei Hwu, All Rights Reserved54
Method Area
Method Tables Example
Method Table forOfficeMate Class
Java Heap
copyfax Code for
OfficeMate
Code forLaserPrinter
Java Stack
OfficeMate object
Reference to OfficeMate object
method table ptr.
Fields
© 1999, Wen-mei Hwu, All Rights Reserved55
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
© 1999, Wen-mei Hwu, All Rights Reserved56
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)
© 1999, Wen-mei Hwu, All Rights Reserved57
Method Tables
OfficeMate
copyfax
Code forOfficeMate
Code forLaserPrinter
Code forEasyFax
LaserPrinter
fax
EasyFax
DotMatrix
Code forDotMatrix
Methods implementing abstract class Printer Methods implementing interface FaxMachine
... ... ... ...
© 1999, Wen-mei Hwu, All Rights Reserved58
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
© 1999, Wen-mei Hwu, All Rights Reserved59
Runtime Method Resolution with Compiled Code
r1 mem[object_reference]Virtual Callr2 mem[r1+Table_Off_In_Object]call [r2 + Method_Off_In_Table]Interface Callpush r1push InterfaceIDcall resolveInterfaceOffset(r2 result)call [r2 + Meth_Off_In_Interface]
Load object ref
Load ptr to meth tblIndirect call to virtual
methodObject Ref (Param1)Intrface ID (Param2)
Search Method TblOffset of interface
Indirect call to interface method
© 1999, Wen-mei Hwu, All Rights Reserved60
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
© 1999, Wen-mei Hwu, All Rights Reserved61
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
© 1999, Wen-mei Hwu, All Rights Reserved62
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
© 1999, Wen-mei Hwu, All Rights Reserved63
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
© 1999, Wen-mei Hwu, All Rights Reserved64
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
© 1999, Wen-mei Hwu, All Rights Reserved65
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); } }}
© 1999, Wen-mei Hwu, All Rights Reserved66
Java Runtime Support Outline• Execution Models• Verification• Dynamic Linking• Dynamic Extension/Loading• Garbage Collection• Exception Handling
© 1999, Wen-mei Hwu, All Rights Reserved67
Java Runtime Environment (JRE)
beans
sqltextrmi
security ioawt
net util lang
Java VirtualMachine
Open VMS
Java Core API
JavaOS Win NTMacSolarisWin 95/98UnixWareIRIXHP-UXAIX
OS/2 OthersUXP/DSRISC OSOS/390
© 1999, Wen-mei Hwu, All Rights Reserved68
Java Runtime OverviewJava
Source
Javacompiler
Bytecode(.class)
ClassLoader
Bytecodeverifier
ConstantPool
Interpreter JIT
Memory Manager
SecurityManager
Services GUIOperating System
Hardware
Execution Engine
Java VM
© 1999, Wen-mei Hwu, All Rights Reserved69
Basic elements of the JVM• Bytecode execution
– Interpreter– JIT– Static Compilation– Java Processors
© 1999, Wen-mei Hwu, All Rights Reserved70
Basic elements of the JVM• Memory management
– garbage collection• Class loading• Class file and bytecode verification
© 1999, Wen-mei Hwu, All Rights Reserved71
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
© 1999, Wen-mei Hwu, All Rights Reserved72
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
© 1999, Wen-mei Hwu, All Rights Reserved73
Anatomy of a JIT
Memory
Bytecodeimporter IR Optimizer
CodeGeneratorLinker
BytecodeExecutor
--Runtime
Controller
Java Virtual Machine1 2 3
456
7
8
9
JIT
© 1999, Wen-mei Hwu, All Rights Reserved74
Anatomy of a JIT1 Runtime controller makes JIT request
– passes pointer to memory location of bytecode
2 Bytecode importer obtains bytecode and converts it to internal representation (IR)
3 The internal representation is then optimized
© 1999, Wen-mei Hwu, All Rights Reserved75
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
© 1999, Wen-mei Hwu, All Rights Reserved76
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
© 1999, Wen-mei Hwu, All Rights Reserved77
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
© 1999, Wen-mei Hwu, All Rights Reserved78
HotSpot Summary• Garbage Collection
– exact generational collector– Non-disruptive
• Faster thread synchronization– reduction of overhead on
allocation and deallocation of thread spaces
© 1999, Wen-mei Hwu, All Rights Reserved79
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
© 1999, Wen-mei Hwu, All Rights Reserved80
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
© 1999, Wen-mei Hwu, All Rights Reserved81
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
© 1999, Wen-mei Hwu, All Rights Reserved82
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
© 1999, Wen-mei Hwu, All Rights Reserved83
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…)
© 1999, Wen-mei Hwu, All Rights Reserved84
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
© 1999, Wen-mei Hwu, All Rights Reserved85
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
© 1999, Wen-mei Hwu, All Rights Reserved86
Dynamic Loading Example
interface QueryDriver { String processQuery(String command);}
// This class is unknown at compile timeclass DynamicDriver implements QueryDriver { public String processQuery(String command)
{ … }}
© 1999, Wen-mei Hwu, All Rights Reserved87
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 } }}
© 1999, Wen-mei Hwu, All Rights Reserved88
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
© 1999, Wen-mei Hwu, All Rights Reserved89
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
© 1999, Wen-mei Hwu, All Rights Reserved90
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
© 1999, Wen-mei Hwu, All Rights Reserved91
Support for Dynamic Loading in Static Compilers
• 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
© 1999, Wen-mei Hwu, All Rights Reserved92
Support for Dynamic Loading in Static Compilers
• Optimization tradeoffs– Reduces ability to optimize interface
calls: can’t establish constant method table offset
© 1999, Wen-mei Hwu, All Rights Reserved93
Garbage CollectionType I: Reference counting
Root Set
1
.
.
.
.
Heap Space A:
B:
C:
X:
D: E:
H:G:
F:2 1
2
11
1
11
© 1999, Wen-mei Hwu, All Rights Reserved94
Garbage CollectionType I: Reference counting (cont.)
Root Set
1
.
.
.
.
Heap Space A:
B:
C:
X:
D: E:
H:G:
F:2 1
1
11
1
11
A-B-C forma circle
© 1999, Wen-mei Hwu, All Rights Reserved95
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
© 1999, Wen-mei Hwu, All Rights Reserved96
Garbage CollectionType III: Copying
Root Set
From Space
A:
C:B:
D:
To Space
A B C DA B D D
E:
© 1999, Wen-mei Hwu, All Rights Reserved97
Garbage CollectionType III: Copying (cont.)
GarbageLive object
time
heapallocated size
© 1999, Wen-mei Hwu, All Rights Reserved98
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)
© 1999, Wen-mei Hwu, All Rights Reserved99
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.)
© 1999, Wen-mei Hwu, All Rights Reserved100
• 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
© 1999, Wen-mei Hwu, All Rights Reserved101
• 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
Garbage CollectionType IV: Generational
© 1999, Wen-mei Hwu, All Rights Reserved102
• 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
© 1999, Wen-mei Hwu, All Rights Reserved103
Garbage CollectionType IV: Generational (cont.)
GarbageLive object
time
sizeFirst Generation
Second Generation
Third Generation
Recursive collect
© 1999, Wen-mei Hwu, All Rights Reserved104
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
© 1999, Wen-mei Hwu, All Rights Reserved105
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()
© 1999, Wen-mei Hwu, All Rights Reserved106
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.)
© 1999, Wen-mei Hwu, All Rights Reserved107
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
© 1999, Wen-mei Hwu, All Rights Reserved108
VM vs. User Exceptions• User thrown exceptions must be
explicitly declared and thrown with a throw statement
© 1999, Wen-mei Hwu, All Rights Reserved109
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
© 1999, Wen-mei Hwu, All Rights Reserved110
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
© 1999, Wen-mei Hwu, All Rights Reserved111
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); }}
© 1999, Wen-mei Hwu, All Rights Reserved112
// 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();}
© 1999, Wen-mei Hwu, All Rights Reserved113
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); } ...}
© 1999, Wen-mei Hwu, All Rights Reserved114
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;}
© 1999, Wen-mei Hwu, All Rights Reserved115
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)
© 1999, Wen-mei Hwu, All Rights Reserved116
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;}
© 1999, Wen-mei Hwu, All Rights Reserved117
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
© 1999, Wen-mei Hwu, All Rights Reserved118
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
© 1999, Wen-mei Hwu, All Rights Reserved119
Finally/Exception TablesJava method
void run() throws Exception { int i = 0; try { i++; } finally { i++; } // i always equals 2 here}
© 1999, Wen-mei Hwu, All Rights Reserved120
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
© 1999, Wen-mei Hwu, All Rights Reserved121
Exception handling considerations
• Two types– catastrophic: program terminates– non-catastrophic: execution
continues after code in catch block is executed
© 1999, Wen-mei Hwu, All Rights Reserved122
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
© 1999, Wen-mei Hwu, All Rights Reserved123
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
© 1999, Wen-mei Hwu, All Rights Reserved124
Java Core API Overview• Set of runtime libraries providing a
standard way to access system resources
• Notable API features– Threads– Serialization– Reflection/Introspection– RMI
© 1999, Wen-mei Hwu, All Rights Reserved125
Some standard API groups– AWT- graphical user interfaces– IO - standard IO– LANG - basic language support– NET - network communications– UTIL - data structure and
collections
© 1999, Wen-mei Hwu, All Rights Reserved126
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
© 1999, Wen-mei Hwu, All Rights Reserved127
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
© 1999, Wen-mei Hwu, All Rights Reserved128
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)
© 1999, Wen-mei Hwu, All Rights Reserved129
Cooperative Synchronization
object
thread1count=1
thread2thread3thread4
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
thread2count=1
thread3thread4thread1
monitor
wait set
heap space(after)
(blocked) (blocked)
(runnable)(runnable)
Thread1 executes:
© 1999, Wen-mei Hwu, All Rights Reserved130
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)
© 1999, Wen-mei Hwu, All Rights Reserved131
Serialization Uses• Persistent objects - let objects “stick
around” between program invocations– Archives and Databases– Checkpoint/Restart to limit data
loss or for job-scheduling
© 1999, Wen-mei Hwu, All Rights Reserved132
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
© 1999, Wen-mei Hwu, All Rights Reserved133
Program Instance #2Program Instance #1
File/Network Stream
Serialization Diagram
© 1999, Wen-mei Hwu, All Rights Reserved134
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)
© 1999, Wen-mei Hwu, All Rights Reserved135
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)
© 1999, Wen-mei Hwu, All Rights Reserved136
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)
© 1999, Wen-mei Hwu, All Rights Reserved137
Using Reflectioninterface Toy {}
class Frisbeeimplements Toy {}
class Stickimplements 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());...
© 1999, Wen-mei Hwu, All Rights Reserved138
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());...
© 1999, Wen-mei Hwu, All Rights Reserved139
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
© 1999, Wen-mei Hwu, All Rights Reserved140
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)
© 1999, Wen-mei Hwu, All Rights Reserved141
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)
© 1999, Wen-mei Hwu, All Rights Reserved142
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
© 1999, Wen-mei Hwu, All Rights Reserved143
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
© 1999, Wen-mei Hwu, All Rights Reserved144
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
registeredevent listeners
Run Query
© 1999, Wen-mei Hwu, All Rights Reserved145
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
© 1999, Wen-mei Hwu, All Rights Reserved146
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
© 1999, Wen-mei Hwu, All Rights Reserved147
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
© 1999, Wen-mei Hwu, All Rights Reserved148
Server MachineClient Machine
Server VM
RMI Diagram
Client VMClientObject
ProxyStub
SkeletonObject
ServerObject
Network
LocalRegistry
Unique Name
© 1999, Wen-mei Hwu, All Rights Reserved149
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
© 1999, Wen-mei Hwu, All Rights Reserved150
Related technologies• COM
– Microsoft Component Object Model– Packages objects as interoperable
“components”• provide well defined services• visible to independently
developed applications– Cross language support
© 1999, Wen-mei Hwu, All Rights Reserved151
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
© 1999, Wen-mei Hwu, All Rights Reserved152
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)
© 1999, Wen-mei Hwu, All Rights Reserved153
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
© 1999, Wen-mei Hwu, All Rights Reserved154
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
© 1999, Wen-mei Hwu, All Rights Reserved155
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)
© 1999, Wen-mei Hwu, All Rights Reserved156
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
© 1999, Wen-mei Hwu, All Rights Reserved157
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 fieldsInterface A
Interface AMethods..
COM Object COM ClassMethod Table
Interface B
Interface B Ptr.
...Interface BMethods..
© 1999, Wen-mei Hwu, All Rights Reserved158
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
© 1999, Wen-mei Hwu, All Rights Reserved159
Java/COM IntegrationVisual Basic
Program
COMInterface
RegularCOM Object
MSJAVA.DLL
JavaProgram
Java Class w/COM Attribute
(wrapper)Init VM,
Create instanceof Java COM obj.
RegularJava
Classes
COM Object
COMInterface
© 1999, Wen-mei Hwu, All Rights Reserved160
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)
© 1999, Wen-mei Hwu, All Rights Reserved161
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.
© 1999, Wen-mei Hwu, All Rights Reserved162
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
© 1999, Wen-mei Hwu, All Rights Reserved163
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
© 1999, Wen-mei Hwu, All Rights Reserved164
DCOM Architecture Example
Microsoft VM
DCOMServerControlManager
Remote System with DCOM support
SCM
anonymousobject
anonymousobject
COM skeleton
COM skeleton
COM proxy
COM proxy
Java client B
Java client A
© 1999, Wen-mei Hwu, All Rights Reserved165
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
© 1999, Wen-mei Hwu, All Rights Reserved166
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
© 1999, Wen-mei Hwu, All Rights Reserved167
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
© 1999, Wen-mei Hwu, All Rights Reserved168
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)
© 1999, Wen-mei Hwu, All Rights Reserved169
C++ORB
Java VM
JavaORB
Remote System (C++ code)IIOP
CORBA Architecture
IR IR
Java client A
Java client A
client stub
client stub
server skeleton
shared object
© 1999, Wen-mei Hwu, All Rights Reserved170
Java Developments• Personal Java• Embedded Java• Java Card• JavaOS
© 1999, Wen-mei Hwu, All Rights Reserved171
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.
© 1999, Wen-mei Hwu, All Rights Reserved172
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
© 1999, Wen-mei Hwu, All Rights Reserved173
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
© 1999, Wen-mei Hwu, All Rights Reserved174
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
© 1999, Wen-mei Hwu, All Rights Reserved175
ApplicationClasses
Embedded JavaClasses
HardwareClasses
filter and compact code
ROMjava.c
StaticData
compact data
staticData.cDeveloperEmbedded JavaVendor
Native compiler
nativelinker
ROMlet
staticData.oROMjava.o
nativemethods
VirtualMachine
OS image
Embedded Java Components
© 1999, Wen-mei Hwu, All Rights Reserved176
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
© 1999, Wen-mei Hwu, All Rights Reserved177
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
© 1999, Wen-mei Hwu, All Rights Reserved178
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
© 1999, Wen-mei Hwu, All Rights Reserved179
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
© 1999, Wen-mei Hwu, All Rights Reserved180
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)
© 1999, Wen-mei Hwu, All Rights Reserved181
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)
© 1999, Wen-mei Hwu, All Rights Reserved182
JavaCard Split VM• Off-card
– Class loading, linking, resolution – Verification – Bytecode optimization and
conversions• On-card
– Bytecode execution
© 1999, Wen-mei Hwu, All Rights Reserved183
Java Card Applets• Additional framework for card
applets– Communications protocol w/
terminal– File system compatible w/ industry
standard– Cryptographic functions
© 1999, Wen-mei Hwu, All Rights Reserved184
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
© 1999, Wen-mei Hwu, All Rights Reserved185
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
© 1999, Wen-mei Hwu, All Rights Reserved186
Java Card Considerations• Memory space is limited
– Applets should create and initialize all necessary objects at installation to avoid hitting memory limit at runtime
© 1999, Wen-mei Hwu, All Rights Reserved187
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)
© 1999, Wen-mei Hwu, All Rights Reserved188
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
© 1999, Wen-mei Hwu, All Rights Reserved189
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)
© 1999, Wen-mei Hwu, All Rights Reserved190
JavaOS Runtime
Core Java Classes
Java Language Classes
AWTClasses
I/OClasses
Java Virtual Machine AWTSupport
I/OSupport
JavaOSDevice Drivers
JavaOS Platform Interface
JavaOS Microkernel
JavaOS Components
© 1999, Wen-mei Hwu, All Rights Reserved191
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.
© 1999, Wen-mei Hwu, All Rights Reserved192
Java Programming• Bruce Eckel. Thinking in Java.
Prentice Hall, 1998. http://www.BruceEckel.com
• David Flanagan. Java in a Nutshell. O'Reilly, 1997.
© 1999, Wen-mei Hwu, All Rights Reserved193
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
© 1999, Wen-mei Hwu, All Rights Reserved194
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.
© 1999, Wen-mei Hwu, All Rights Reserved195
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.
© 1999, Wen-mei Hwu, All Rights Reserved196
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/
© 1999, Wen-mei Hwu, All Rights Reserved197
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
© 1999, Wen-mei Hwu, All Rights Reserved198
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/