Java Virtual Machine VM Architecture Software Architecture Implementations

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 3 rd-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 Canadian. Address – 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 Canadian. Address(‘ 75 John Street’, ‘N 2 L 3 X 2’)) © 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. short. Zip() 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. short. Zip() © 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 r 2 ¬ pop(B) r 1¬ pop(A) r 3 ¬ r 1+r 2 push r 3 © 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 0 x 0005. . . Constant pool. . . Stack frame © 1999, Wen-mei Hwu, All Rights Reserved Constant Pool. . . 5 Method ref. . . 8 class ref. . . a Name & type. . . d “add”. . . 11 ‘(‘ ‘I’ ‘)’ ‘I’ 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 Dot. Matrix Laser. Printer Copier Fax. Machine Interface Extends Implements Office. Mate. Plus • 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 make. Copies(); } // Override Printer. print() class Dot. Matrix extends Printer void print() { // dot matrix printer code. . . }} interface Fax. Machine { void send. Fax(); } // Override Printer. print() class Laser. Printer extends Printer { void print() { // laser printer code. . . }} © 1999, Wen-mei Hwu, All Rights Reserved // Provide code for Copier and // Fax. Machine interfaces // Inherit code from Laser. Printer class Office. Mate. Plus extends Laser. Printer implements Copier, Fax. Machine { void make. Copies() { // code to make copies. . . } void send. Fax() { // code to send a fax. . . } } 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 Trained. Employee { void Print. Document( Printer p) { p. print(); // Virtual call } void replicate. Document( Copier c) { // Interface call c. make. Copies(); } void fax. Document( Fax. Machine f) { // Interface call f. send. Fax(); } } © 1999, Wen-mei Hwu, All Rights Reserved // More office equipment class Quick. Copier implements Copier { public void make. Copies() { … } } class Easy. Fax implements Fax. Machine { public void send. Fax() { … } } 49

Revisiting Class/Interface Example // Create a new Trained. Employee e = new Trained. Employee(); // Create office equipment objects Dot. Matrix dm = new Dot. Matrix(); Quick. Copier qc = new Quick. Copier(); Easy. Fax ef = new Easy. Fax(); // Trained. Employee can use all // three machines e. print. Document(dm); e. replicate. Document(qc); e. fax. Document(ef); © 1999, Wen-mei Hwu, All Rights Reserved // Upgrade to the Office. Mate. Plus o = new Office. Mate. Plus(); // Trained employee can do // everything with one machine // by using different interfaces // depending on the situation e. print. Document(o); e. replicate. Document(o); e. fax. Document(o); // Polymorphism means you // don’t have to retrain your // employee 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 © 1999, Wen-mei Hwu, All Rights Reserved Iterates through the data structure. Draws each shape in the collection. No need to recompile 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 Office. Mate object Java Heap Office. Mate object Method Area Method Table for Office. Mate Class method table ptr. Fields © 1999, Wen-mei Hwu, All Rights Reserved print Code for Laser. Printer copy fax Code for Office. Mate 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 Fax. Machine Easy. Fax. . . Dot. Matrix. . . Laser. Printer. . . Office. Mate. . . fax print copy fax Code for Easy. Fax Code for Dot. Matrix Code for Laser. Printer © 1999, Wen-mei Hwu, All Rights Reserved Code for Office. Mate 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 r 1 ¬ mem[object_reference] Virtual Call Load ptr to meth tbl r 2 ¬ mem[r 1+Table_Off_In_Object] Indirect call to virtual call [r 2 + Method_Off_In_Table] method Interface Call Object Ref (Param 1) push r 1 Intrface ID (Param 2) push Interface. ID Search Method Tbl call resolve. Interface. Offset of interface (r 2 ¬ result) Indirect call to call [r 2 + 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 Check. Cast • Returns ZERO on failure, ONE on success © 1999, Wen-mei Hwu, All Rights Reserved 64

Check. Cast/Instance. Of Example public class Housing { Vector kennel = new Vector(); Vector natural_habitat = new Vector(); void house. Animals(Enumeration homeless) { while (homeless. has. More. Elements()) { // Enumeration returns an element of type Object // Compiler must insert Check. Cast bytecode here Animal a = (Animal) homeless. next. Element(); // Compiler must insert Instance. Of bytecode here if (a instanceof Dog) kennel. add. Element(a); else natural_habitat. add. Element(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 beans Java. OS AIX OS/2 Win 95/98 HP-UX OS/390 text sql awt security io net Java Virtual Machine rmi util lang Solaris IRIX RISC OS © 1999, Wen-mei Hwu, All Rights Reserved Mac Win NT Open VMS Unix. Ware UXP/DS Others 67

Java Runtime Overview Java Source Java VM 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

Hot. Spot 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

Hot. Spot 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 Query. Driver { String process. Query(String command); } // This class is unknown at compile time class Dynamic. Driver implements Query. Driver { public String process. Query(String command) { … } } © 1999, Wen-mei Hwu, All Rights Reserved 86

class Dynamic. Loader { void run(String driver_name) throws Class. Not. Found. Exception, Illegal. Access. Exception, Instantiation. Exception { // Instruct class loader to create named class Class driver_class = Class. for. Name(driver_name); try { // Create a new instance of the driver // class, cast to Query. Driver driver = (Query. Driver) driver_class. new. Instance(); String command = get. Input(); // If cast succeeded, driver implements process. Query String result = driver. process. Query(command); } catch(Class. Cast. Exception 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 D: 1 F: 1 E: 1 G: 2 © 1999, Wen-mei Hwu, All Rights Reserved H: 1 93

Garbage Collection Type I: Reference counting (cont. ) Heap Space Root Set A: 1 X: . . B: 1 1 C: 1 D: F: 1 E: 1 A-B-C form a circle 1 G: 2 © 1999, Wen-mei Hwu, All Rights Reserved H: 1 94

Garbage Collection Type II: Marking & Sweeping Heap Space Root Set A: X: . . . B: C: D: F: E: G: © 1999, Wen-mei Hwu, All Rights Reserved H: Mark Bits - - AF- - C - X- - F - B - G- - DH 95

Garbage Collection From Space Type III: Copying 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 © 1999, Wen-mei Hwu, All Rights Reserved time 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 get. Message() – void print. Stack. Trace() © 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 (Out. Of. Memory, etc. ) • Dynamic Linking (Class. Format. Error, etc. ) © 1999, Wen-mei Hwu, All Rights Reserved 106

VM vs. User Exceptions • VM thrown exceptions – Derived from Runtime. Exception, 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 Database. Exception extends Exception {} class Index. Exception extends Database. Exception {} class Read. Exception extends Database. Exception {} class Vendor. Database { int get. Offset. For. ID(int id) throws Index. Exception {. . . } String read. Name(int offs) throws Record. Read. Exception {. . . } // Let higher context decide what to do about // different exceptions String get. Name. For. ID(int id) throws Index. Exception, Read. Exception { int offs = get. Offset. For. ID(id); return read. Name(offs); } } © 1999, Wen-mei Hwu, All Rights Reserved 111

// User Code: display name in box // or display appropriate error void show. Record(Dialog msgbox, Vendor. Database data, int id) { String message; try { message = data. get. Name. For. ID(id); } // Don’t care which type of database exception // occurred, but want to handle it nicely catch (Database. Exception e) { message = "Data unavailable: ” + e. get. Message(); } msgbox. set. Title(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 get. Offset. For. ID(int id, int *offset) {. . . // Difficult to provide detailed information // to a higher context if (errorcondition) return -1; else return 0; } // Alternative: cause termination char *read. Name(int offs) {. . . if (errorcondition) { perror(“Bad database format”); exit(-1); }. . . } © 1999, Wen-mei Hwu, All Rights Reserved 113

Typical C Error Handling int get. Name. For. ID(int id, char **str) { int result // Error checking complicates all intermediate layers if (get. Offset. For. ID(id, &result) != 0) return -1; } // User code now has no way to handle errors // inside read. Name library function or to provide a // different reporting mechanism (other than perror) *str = read. Name(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 Name. From. File(User. File file, Vendor. Database data) throws Database. Exception, IOException { String name; file. open(); try { int id = file. read. Int(); name = data. get. Name. For. ID(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: © 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 maintained © 1999, Wen-mei Hwu, All Rights Reserved state reset Restricts code motion 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 © 1999, Wen-mei Hwu, All Rights Reserved LV[2] alive later 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) Thread 1 executes: heap space (after) object. notify() object monitor thread 1 count=1 (runnable) wait set thread 2 thread 3 notifies next waiting thread (thread 2) object. wait() relinquishes object’s monitor and enters the wait set allowing thread 2 to acquire the monitor thread 4 (blocked) © 1999, Wen-mei Hwu, All Rights Reserved monitor thread 2 count=1 (runnable) wait set thread 3 thread 4 thread 1 (blocked) 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 © 1999, Wen-mei Hwu, All Rights Reserved Program Instance #2 133

Reflection API • Support for querying the internals of a class Constructor[] Class. get. Constructors() Constructor Class. get. Constructor(Class[] param. Types) Method[] Class. get. Methods() Method Class. get. Method(String name, Class[] param. Types) Field[] Class. get. Fields() Field Class. get. Field(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. new. Instance(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 (Java. Beans) © 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 play. With. Dog(Dog dog, String game_name, Toy toy) { Method game = Dog. class. get. Method(game_name, Class[] {Toy. class} ); game. invoke(dog, toy); } © 1999, Wen-mei Hwu, All Rights Reserved . . . Dog corky = new Dog(); play. With. Dog(corky, “fetch”, new Stick()); play. With. Dog(corky, “chew”, new Frisbee()); . . . 138

Java. Beans • Build customizable software components in Java • A component (Java class) can simply use a standard naming convention to “publish” its interface as a Java. Bean • Standard naming defines a bean’s properties, methods, and events © 1999, Wen-mei Hwu, All Rights Reserved 139

Java. Beans • 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 3 rd 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. mouse. Click. Event -> 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 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 VM Client Proxy Object Skeleton Stub 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++, Visual. Basic) © 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 (Query. Interface) – Reference Counting (Add. Ref/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 Ptr. Interface B. . . © 1999, Wen-mei Hwu, All Rights Reserved COM Class Method Table Interface A Methods. . Interface B Methods. . 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 Regular Java Classes Java Class w/ COM Attribute (wrapper) Init VM, Create instance of Java COM obj. Regular COM Object COM Interface MSJAVA. DLL © 1999, Wen-mei Hwu, All Rights Reserved COM Object 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 © 1999, Wen-mei Hwu, All Rights Reserved S C M COM skeleton anonymous object 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 3 rd 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 3 rd 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 client stub Remote System (C++ code) IIOP C++ ORB IR Java client A Java IR server skeleton shared object client stub © 1999, Wen-mei Hwu, All Rights Reserved 169

Java Developments • • Personal Java Embedded Java Card Java. OS © 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-1 MB 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 Virtual Machine OS image ROMjava. c compact data static. Data. c Native compiler ROMjava. o native linker © 1999, Wen-mei Hwu, All Rights Reserved static. Data. o native methods ROMlet 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

Java. Card Goals • Allow “smart card” developers to write code in Java • Device requirements – 16 K of ROM – 8 K of EEPROM (non-volatile) – 256 bytes of RAM © 1999, Wen-mei Hwu, All Rights Reserved 179

Java. Card 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

Java. Card 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

Java. Card 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 Java. Card 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

Java. OS 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

Java. OS 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

Java. OS Architecture Layers • Microkernel and Memory Manager (native) • Device Drivers (mostly bytecode) • Java Virtual Machine (bytecode, calls native system functions) • Java. OS Graphics and Windowing systems (bytecode) • Full Java API (bytecode) © 1999, Wen-mei Hwu, All Rights Reserved 189

Java. OS Components Core Java Classes Java Language Classes AWT Classes I/O Classes Java Virtual Machine AWT Support I/O Support Java. OS Device Drivers Java. OS Runtime Java. OS Platform Interface Java. OS 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. Bruce. Eckel. 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. Mc. Graw-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. 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 Reserved 195

Static, Java to native compilers: • Supercede, Inc. , Supercede, www. supercede. com • Tower Technology Corporation, Tower. J, www. twr. com • Symantec Corporation, Visual. Cafe, www. symantec. com/domain/cafe/ • Open Group Research Institute, Turbo. J, 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/ • Java. Beans, www. javasoft. com/beans/ • Java. OS, www. sun. com/javaos/ • Personal Java Specification, www. javasoft. com/products/personaljava/ • pico. Jaca Microprocessor core, www. sun. com /microelectronics/whitepapers/wpr-0014 -01/ © 1999, Wen-mei Hwu, All Rights Reserved 198