Transcript 23. Virtual Machines

Java Virtual Machine: VM Architecture,
Software Architecture,
Implementations, and Application
Programming Interfaces
Wen-mei Hwu
Department of ECE
University of Illinois
© 1999, Wen-mei Hwu, All Rights Reserved
1
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 Reserved
2
Outline
•
•
•
•
•
•
•
Introduction
Basic Bytecode Architecture
Java Objects
Java Runtime
Java Core API
Related Technologies
Java Related Developments
© 1999, Wen-mei Hwu, All Rights Reserved
3
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 Reserved
4
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 Reserved
5
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 Reserved
6
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 Reserved
7
Development Environment
• Language features
– Automatic memory management
– Structured exception handling
– Object-oriented design
© 1999, Wen-mei Hwu, All Rights Reserved
8
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 Reserved
9
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 Reserved
10
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 Reserved
11
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 Reserved
12
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 Reserved
13
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 Reserved
14
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 Reserved
15
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 Reserved
16
Database Example
Insert 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 Reserved
17
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 Reserved
18
Database Example
• Query an address
– Short zip method runs on client
SELECT name, address FROM employees
WHERE ID = ‘1001’
INTO cust_name, cust_address
IF cust_address.state = “IL” THEN
PRINT “Local Customer:” + cust_name
+ “ Zip:” + cust_address.shortZip()
© 1999, Wen-mei Hwu, All Rights Reserved
19
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 Reserved
20
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 Reserved
21
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 Reserved
22
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 loadstore architectures
© 1999, Wen-mei Hwu, All Rights Reserved
23
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 Reserved
24
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 Reserved
25
Stack Computation Model
Example: add
Stack operation
Translated code
push A
push B
add
push A
push B
r2  pop(B)
r1 pop(A)
r3 r1+r2
push r3
© 1999, Wen-mei Hwu, All Rights Reserved
26
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 Reserved
27
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 Reserved
28
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 Reserved
29
Simple example
Invokevirtual 0x0005
...
Constant pool
...
Stack frame
Constant Pool
...
5 Method ref
...
8 class ref
...
a Name & type
...
d “add”
...
11 ‘(‘ ‘I’ ‘I’ ‘)’ ‘I’
© 1999, Wen-mei Hwu, All Rights Reserved
30
Bytecode operation types
• Stack Manipulations
– push, pop, duplicate, swap
• Local Variable accessing
– load, store
• Arrays
– create, store, retrieve
© 1999, Wen-mei Hwu, All Rights Reserved
31
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 Reserved
32
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 Reserved
33
Quick Opcodes
• 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
© 1999, Wen-mei Hwu, All Rights Reserved
34
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 Reserved
35
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 Reserved
36
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 Reserved
37
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 Reserved
38
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 Reserved
39
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 Reserved
40
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 Reserved
41
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 Reserved
42
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 Reserved
43
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 Reserved
44
Inheritance Hierarchy
Printer
Class
DotMatrix
LaserPrinter
Copier
FaxMachine
Interface
Extends
Implements
OfficeMatePlus
• A class has only one superclass, but
may have many ancestors
• Implementation of a single class can
then be treated as multiple interfaces
© 1999, Wen-mei Hwu, All Rights Reserved
45
Class/Interface Definition Example
// Defer Printer implementation
abstract class Printer {
abstract void print(); }
// Interfaces contain no code
interface Copier {
void makeCopies();
}
// Override Printer.print()
class DotMatrix extends
Printer
void print() {
// dot matrix printer code ...
}}
interface FaxMachine {
void sendFax();
}
// Override Printer.print()
class LaserPrinter extends
Printer {
void print() {
// laser printer code ...
}}
// Provide code for Copier and
// FaxMachine interfaces
// Inherit code from LaserPrinter
class 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 Reserved
46
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 Reserved
47
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 Reserved
48
Revisiting Class/Interface Example
// Can use three types of machines
class 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 EasyFax
implements FaxMachine {
public void
sendFax() { … }
}
© 1999, Wen-mei Hwu, All Rights Reserved
49
Revisiting Class/Interface Example
// Create a new TrainedEmployee
TrainedEmployee e = new
TrainedEmployee();
// Create office equipment objects
DotMatrix dm = new
DotMatrix();
QuickCopier qc = new
QuickCopier();
EasyFax ef = new
EasyFax();
// TrainedEmployee can use all
// three machines
e.printDocument(dm);
e.replicateDocument(qc);
e.faxDocument(ef);
// Upgrade to the OfficeMatePlus
OfficeMatePlus o = new
OfficeMatePlus();
// Trained employee can do
// everything with one machine
// by using different interfaces
// depending on the situation
e.printDocument(o);
e.replicateDocument(o);
e.faxDocument(o);
// Polymorphism means you
// don’t have to retrain your
// employee
© 1999, Wen-mei Hwu, All Rights Reserved
50
Real-World Example
• Client code has collection of shapes that
must be drawn by Vendor code
Client Code - Evolves
Stores a
collection
of shapes
in custom
data
structure
Passes the
structure
to Library
Routine
Queue
Binary
Tree
Hash
Table
Queue_
Iterator
Tree_
Iterator
Vendor Code
Library Routine
Iterator
(Interface)
Table_
Iterator
Iterates
through the
data structure.
Draws each
shape in the
collection.
No need to recompile
© 1999, Wen-mei Hwu, All Rights Reserved
51
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 Reserved
52
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 Reserved
53
Method Tables Example
Java Stack
Reference to
OfficeMate object
Method Area
Java Heap
OfficeMate object
Method Table for
OfficeMate Class
method table ptr.
print
Code for
LaserPrinter
copy
Fields
fax
Code for
OfficeMate
© 1999, Wen-mei Hwu, All Rights Reserved
54
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 Reserved
55
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 Reserved
56
Method Tables
Methods implementing abstract class Printer
Methods implementing interface FaxMachine
EasyFax
...
DotMatrix
...
LaserPrinter
...
OfficeMate
...
fax
print
print
print
copy
fax
Code for
EasyFax
Code for
DotMatrix
Code for
LaserPrinter
Code for
OfficeMate
© 1999, Wen-mei Hwu, All Rights Reserved
57
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 Reserved
58
Runtime Method Resolution
with Compiled Code
Load object ref r1  mem[object_reference]
Virtual Call
Load ptr to meth tbl r2 mem[r1+Table_Off_In_Object]
Indirect call to virtual call [r2 + Method_Off_In_Table]
method Interface Call
Object Ref (Param1) push r1
Intrface ID (Param2) push InterfaceID
Search Method Tbl call resolveInterfaceOffset
Offset of interface (r2  result)
Indirect call to call [r2 + Meth_Off_In_Interface]
interface method
© 1999, Wen-mei Hwu, All Rights Reserved
59
Static Optimization for
Interface 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 Reserved
60
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 Reserved
61
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 Reserved
62
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 Reserved
63
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 Reserved
64
CheckCast/InstanceOf Example
public 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 Reserved
65
Java Runtime Support Outline
•
•
•
•
•
•
Execution Models
Verification
Dynamic Linking
Dynamic Extension/Loading
Garbage Collection
Exception Handling
© 1999, Wen-mei Hwu, All Rights Reserved
66
Java Runtime Environment (JRE)
Java Core API
Java Virtual
Machine
JavaOS
AIX
OS/2
Win 95/98
HP-UX
OS/390
beans
rmi
text
sql
awt
security
io
net
util
lang
Solaris
IRIX
RISC OS
Mac
Win NT
Open VMS UnixWare
UXP/DS
Others
© 1999, Wen-mei Hwu, All Rights Reserved
67
Java Runtime Overview
Java VM
Java
Source
Class
Loader
Constant
Pool
Bytecode
verifier
Java
compiler
Execution Engine
Interpreter
Bytecode
(.class)
Services
Memory
Manager
JIT
Security
Manager
GUI
Operating System
Hardware
© 1999, Wen-mei Hwu, All Rights Reserved
68
Basic elements of the JVM
• Bytecode execution
– Interpreter
– JIT
– Static Compilation
– Java Processors
© 1999, Wen-mei Hwu, All Rights Reserved
69
Basic elements of the JVM
• Memory management
– garbage collection
• Class loading
• Class file and bytecode verification
© 1999, Wen-mei Hwu, All Rights Reserved
70
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 Reserved
71
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 methodpointer table
© 1999, Wen-mei Hwu, All Rights Reserved
72
Anatomy of a JIT
Java Virtual Machine
Bytecode 1 Bytecode 2
IR
Executor
importer
-5
Runtime
8 Linker
Controller
6
JIT
9
3
Optimizer
4
Code
Generator
7
Memory
© 1999, Wen-mei Hwu, All Rights Reserved
73
Anatomy of a JIT
1 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 Reserved
74
Anatomy of a JIT
4 Code generator generates native code
from IR
5 Code generator requests needed
memory from runtime controller
– runtime controller passes back
pointer to requested memory
6 Linker performs traditional linker
functions
© 1999, Wen-mei Hwu, All Rights Reserved
75
Anatomy of a JIT
7 Linker places native code in memory at
location specified runtime controller
8 Linker provides controller information
concerning native code to the runtime
controller
9 Runtime controller responsible for
memory management
© 1999, Wen-mei Hwu, All Rights Reserved
76
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 Reserved
77
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 Reserved
78
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 Reserved
79
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 Reserved
80
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 Reserved
81
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 Reserved
82
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 Reserved
83
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 Reserved
84
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 Reserved
85
Dynamic Loading Example
interface QueryDriver {
String processQuery(String command);
}
// This class is unknown at compile time
class DynamicDriver implements QueryDriver {
public String processQuery(String command) { …
}
}
© 1999, Wen-mei Hwu, All Rights Reserved
86
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 Reserved
87
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 Reserved
88
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 Reserved
89
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 Reserved
90
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 Reserved
91
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 Reserved
92
Garbage Collection
Type I: Reference counting
Heap Space
Root
Set
A: 2
X:
.
.
.
.
B: 1
1
C: 1
F:
1
D:
E:
1
1
G:
2
H:
1
© 1999, Wen-mei Hwu, All Rights Reserved
93
Garbage Collection
Type I: Reference counting (cont.)
Heap Space
Root
Set
A: 1
X:
.
.
.
.
B: 1
1
C: 1
F:
1
D:
E:
1
1
G:
2
A-B-C
form
a circle
H:
1
© 1999, Wen-mei Hwu, All Rights Reserved
94
Garbage Collection
Type II: Marking & Sweeping
Heap Space
Root
Set
A:
X:
.
.
.
.
.
.
B:
C:
D:
F:
E:
G:
H:
Mark Bits
- - AF- - C
- X- - - - F
-
B
-
G- - DH
© 1999, Wen-mei Hwu, All Rights Reserved
95
Garbage Collection
Type III: Copying
From Space
To Space
A:
B:
C:
E:
D:
Root
Set
A A B B C D D D
© 1999, Wen-mei Hwu, All Rights Reserved
96
Garbage Collection
Type III: Copying (cont.)
heap
allocated
size
Garbage
Live object
time
© 1999, Wen-mei Hwu, All Rights Reserved
97
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 Reserved
98
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 Reserved
99
Garbage Collection
Type IV: Generational
• Divide heap into generations
• When current generation fills up,
perform copying collection to move
the objects to the next older
generation (recursive)
© 1999, Wen-mei Hwu, All Rights Reserved
100
Garbage Collection
Type IV: Generational
• Short-lived objects quickly freed
without recopying long-lived objects
– Especially beneficial if longlived=large and short-lived=small
• Only need to scan root-set and
generations newer than one being
collected
© 1999, Wen-mei Hwu, All Rights Reserved
101
Garbage Collection
Type IV: Generational
• 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)
© 1999, Wen-mei Hwu, All Rights Reserved
102
Garbage Collection
Type IV: Generational (cont.)
size
First
Generation
Recursive
collect
Second
Generation
Third
Generation
Garbage
Live object
time
© 1999, Wen-mei Hwu, All Rights Reserved
103
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 Reserved
104
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 Reserved
105
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 Reserved
106
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 Reserved
107
VM vs. User Exceptions
• User thrown exceptions must be
explicitly declared and thrown with a
throw statement
© 1999, Wen-mei Hwu, All Rights Reserved
108
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 Reserved
109
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 Reserved
110
Java Exceptions Example Code
class 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 Reserved
111
// User Code: display name in box
// or display appropriate error
void 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 Reserved
112
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 termination
char *readName(int offs)
{ ...
if (errorcondition) {
perror(“Bad database format”);
exit(-1);
} ...
}
© 1999, Wen-mei Hwu, All Rights Reserved
113
Typical C Error Handling
int 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 Reserved
114
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 Reserved
115
Finally Clause
// User Code: read ID from file, return name
void 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 Reserved
116
Exception Tables
• Compiler attaches an exception table to
each method with a try block
• An entry for each exception handler
contains:
from
to
target
type
first bytecode op inside try block
last bytecode op inside try block
entry point of exception handler
class of exceptions handled
© 1999, Wen-mei Hwu, All Rights Reserved
117
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 Reserved
118
Finally/Exception Tables
Java method
void run() throws Exception {
int i = 0;
try {
i++;
}
finally {
i++;
}
// i always equals 2 here
}
© 1999, Wen-mei Hwu, All Rights Reserved
119
Try block
Compiled Bytecode
Method 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. #3
Exception table:
from
to target type
2
5
9
any
© 1999, Wen-mei Hwu, All Rights Reserved
120
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 Reserved
121
Exception handling considerations
Types of
exceptions
system
user defined
Types
of
behavior
catastrophic
non-catastrophic
Effects
state lost
on
program/machine
state
state maintained
state reset
Restricts code motion
© 1999, Wen-mei Hwu, All Rights Reserved
122
Exception Handler Considerations
def LV[1]
use LV[1]
4’
Try-block
4
5
LV[2] =10/0
use LV[1]
6
8
7
Catch-block
Exception
handler
14
use LV[1]
LV[2] = 1
9
10
LV[2] alive later
© 1999, Wen-mei Hwu, All Rights Reserved
123
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 Reserved
124
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 Reserved
125
Java Threads
• Thread class abstracts underlying OS
to provide standard interface for multithreaded 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 Reserved
126
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 Reserved
127
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 Reserved
128
Cooperative Synchronization
heap space
(before)
Thread1 executes:
heap space
(after)
object
object.notify()
object
monitor
thread1
count=1
(runnable)
wait set
thread2
thread3
notifies next waiting
thread (thread2)
object.wait()
relinquishes
object’s monitor
and enters the wait
set allowing thread2
to acquire the
monitor
thread4
(blocked)
monitor
thread2
count=1
(runnable)
wait set
thread3
thread4
thread1
(blocked)
© 1999, Wen-mei Hwu, All Rights Reserved
129
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 Reserved
130
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 Reserved
131
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 Reserved
132
Serialization Diagram
File/Network
Stream
Program Instance #1
Program Instance #2
© 1999, Wen-mei Hwu, All Rights Reserved
133
Reflection API
• Support for querying the internals of
a class
Constructor[] 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 Reserved
134
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 Reserved
135
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 Reserved
136
Using Reflection
interface 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());
...
© 1999, Wen-mei Hwu, All Rights Reserved
137
Using Reflection
With 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 Reserved
138
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 Reserved
139
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 Reserved
140
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 Reserved
141
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 Reserved
142
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 Reserved
143
Visual Development Example
registered
Button
Register an
event listener
with Button’s
clicked Event
(Initialization)
event listeners
Run Query
Query Viewer
properties
Data Source
Mouse click on
Button invokes
registered
event listeners.
The event
listener calls
Query Viewer’s
run method
Query Command
# Rows to Fetch
© 1999, Wen-mei Hwu, All Rights Reserved
144
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 Reserved
145
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 Reserved
146
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 Reserved
147
RMI Diagram
Client Machine
Server Machine
Server VM
Client VM
Client
Proxy
Object
Stub
Skeleton
Network
Object
Local
Server
Registry
Object
Unique
Name
© 1999, Wen-mei Hwu, All Rights Reserved
148
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 Reserved
149
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 Reserved
150
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 Reserved
151
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 Reserved
152
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 Reserved
153
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 Reserved
154
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 Reserved
155
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 Reserved
156
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 Object
COM Handle
fields
Interface A
Interface B
..
.
Interface B Ptr.
COM Class
Method Table
Interface A
Methods
..
Interface B
Methods
..
© 1999, Wen-mei Hwu, All Rights Reserved
157
Java/COM Integration
• COM interfaces almost identical to
Java interfaces at language level
• Microsoft VM provides bidirectional 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 Reserved
158
Java/COM Integration
Visual Basic
Program
Java
Program
COM
Interface
Java Class w/
COM Attribute
(wrapper)
Init VM,
Create instance
of Java COM obj.
Regular
COM Object
Regular
Java
Classes
COM
Interface
MSJAVA.DLL
COM Object
© 1999, Wen-mei Hwu, All Rights Reserved
159
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 Reserved
160
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 Reserved
161
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 Reserved
162
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 Reserved
163
DCOM Architecture Example
Microsoft VM
Java
client A
COM
proxy
Remote System
with DCOM support
DCOM
Server
Control
Java
client B
COM
proxy
Manager
S
C
M
COM
skeleton
anonymous
object
COM
skeleton
anonymous
object
© 1999, Wen-mei Hwu, All Rights Reserved
164
CORBA Overview
• Standard for distributed, languageindependent 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 Reserved
165
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 Reserved
166
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 Reserved
167
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 Reserved
168
CORBA Architecture
Java VM
Java
client A
Java
client A
client
stub
Remote System
(C++ code)
IIOP
Java
C++
ORB
ORB
IR
IR
server
skeleton
shared
object
client
stub
© 1999, Wen-mei Hwu, All Rights Reserved
169
Java Developments
•
•
•
•
Personal Java
Embedded Java
Java Card
JavaOS
© 1999, Wen-mei Hwu, All Rights Reserved
170
Personal Java
• Target: Network applications on
personal consumer devices (e.g. settop 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 Reserved
171
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 Reserved
172
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 Reserved
173
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 Reserved
174
Embedded Java Components
Application
Classes
Embedded Java
Classes
Hardware
Classes
Static
Data
filter and compact code
Developer
Embedded Java
Vendor
ROMjava.c
OS image
staticData.c
Native compiler
ROMjava.o
Virtual
Machine
compact data
native
linker
staticData.o
native
methods
ROMlet
© 1999, Wen-mei Hwu, All Rights Reserved
175
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 Reserved
176
Personal Java Key Points
• Like standard Java, designed to run
arbitrary applets downloaded across
a network (runs most generalpurpose applets)
• Provides a well-defined subset of
API features; throws exception if the
applications requests an
unsupported operation
© 1999, Wen-mei Hwu, All Rights Reserved
177
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 Reserved
178
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 Reserved
179
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 Reserved
180
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 Reserved
181
JavaCard Split VM
• Off-card
– Class loading, linking, resolution
– Verification
– Bytecode optimization and
conversions
• On-card
– Bytecode execution
© 1999, Wen-mei Hwu, All Rights Reserved
182
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 Reserved
183
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 Reserved
184
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 Reserved
185
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 Reserved
186
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 Reserved
187
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 Reserved
188
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 Reserved
189
JavaOS Components
Core Java Classes
Java Language
Classes
AWT
Classes
I/O
Classes
Java Virtual Machine
AWT
Support
I/O
Support
JavaOS
Device Drivers
JavaOS Runtime
JavaOS Platform Interface
JavaOS Microkernel
© 1999, Wen-mei Hwu, All Rights Reserved
190
Disclaimer
Java 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 Reserved
191
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 Reserved
192
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 Reserved
193
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 Reserved
194
COM
• Don Box. Essential COM. AddisonWesley, 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 Reserved
195
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 Reserved
196
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 Reserved
197
Java Specifications
Sun 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/
© 1999, Wen-mei Hwu, All Rights Reserved
198