1. © 1999, Wen-mei Hwu, All Rights Reserved 1 Java Virtual Machine: VM Architecture, Software Architecture, Implementations, and Application Programming Interfaces Wen-mei Hwu Department of ECE University of Illinois

2. © 1999, Wen-mei Hwu, All Rights Reserved 2 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

3. © 1999, Wen-mei Hwu, All Rights Reserved 3 Outline Introduction Basic Bytecode Architecture Java Objects Java Runtime Java Core API Related Technologies Java Related Developments

4. © 1999, Wen-mei Hwu, All Rights Reserved 4 Java Security Bytecode Level –Disallows pointer manipulation –Provides array bounds checking –Checks for NULL references (pointers) –Eliminates illegal type casting

5. © 1999, Wen-mei Hwu, All Rights Reserved 5 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

6. © 1999, Wen-mei Hwu, All Rights Reserved 6 Java Portability/Mobility Bytecode Level –Binary compatibility: abstracts machine architecture and compiler –Standard module format and compact representation –Dynamic linking and loading

7. © 1999, Wen-mei Hwu, All Rights Reserved 7 Java Portability/Mobility API Level –Operating system abstraction –Consistent support for Threads I/O and Network interface Database Interface Graphical User interface

8. © 1999, Wen-mei Hwu, All Rights Reserved 8 Development Environment Language features –Automatic memory management –Structured exception handling –Object-oriented design

9. © 1999, Wen-mei Hwu, All Rights Reserved 9 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

10. © 1999, Wen-mei Hwu, All Rights Reserved 10 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

11. © 1999, Wen-mei Hwu, All Rights Reserved 11 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

12. © 1999, Wen-mei Hwu, All Rights Reserved 12 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

13. © 1999, Wen-mei Hwu, All Rights Reserved 13 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

14. © 1999, Wen-mei Hwu, All Rights Reserved 14 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

15. © 1999, Wen-mei Hwu, All Rights Reserved 15 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

16. © 1999, Wen-mei Hwu, All Rights Reserved 16 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

17. © 1999, Wen-mei Hwu, All Rights Reserved 17 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’))

18. © 1999, Wen-mei Hwu, All Rights Reserved 18 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

19. © 1999, Wen-mei Hwu, All Rights Reserved 19 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()

20. © 1999, Wen-mei Hwu, All Rights Reserved 20 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

21. © 1999, Wen-mei Hwu, All Rights Reserved 21 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)

22. © 1999, Wen-mei Hwu, All Rights Reserved 22 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

23. © 1999, Wen-mei Hwu, All Rights Reserved 23 Bytecode Architecture Overview Load-store stack architecture –All operands pushed on value stack before use Source operands are fetched from stack and the result is pushed on Equivalent to register file in load- store architectures

24. © 1999, Wen-mei Hwu, All Rights Reserved 24 Bytecode Architecture Overview Extensive support for Java Language and Dynamic Linking –Object manipulation instructions –Method invocation instructions –Exception handling support

25. © 1999, Wen-mei Hwu, All Rights Reserved 25 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

26. © 1999, Wen-mei Hwu, All Rights Reserved 26 Stack Computation Model Example: add Stack operation push A push B add Translated code push A push B r2  pop(B) r1  pop(A) r3  r1+r2 push r3

27. © 1999, Wen-mei Hwu, All Rights Reserved 27 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)

28. © 1999, Wen-mei Hwu, All Rights Reserved 28 Bytecode Modules (Class Files) Bytecode with operands (27.7% of total assigned opcodes) –typically indexes into the constant pool or local variable table

29. © 1999, Wen-mei Hwu, All Rights Reserved 29 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

30. © 1999, Wen-mei Hwu, All Rights Reserved 30 Simple example Invokevirtual 0x0005 Constant pool... Stack frame... 5 Method ref class ref Name & type “add” ‘(‘ ‘I’ ‘I’ ‘)’ ‘I’ 8 a d 11... Constant Pool

31. © 1999, Wen-mei Hwu, All Rights Reserved 31 Bytecode operation types Stack Manipulations –push, pop, duplicate, swap Local Variable accessing –load, store Arrays –create, store, retrieve

32. © 1999, Wen-mei Hwu, All Rights Reserved 32 Bytecode operation types Objects –create, access, set Arithmetic and Type Conversion –add, subtract, multiply, divide, shift, AND, OR, XOR

33. © 1999, Wen-mei Hwu, All Rights Reserved 33 Bytecode operation types Control Flow and Exceptions –conditional, unconditional, goto, local returns, tables, throws Method Calls and Returns –virtual, special, static, interface, returns

34. © 1999, Wen-mei Hwu, All Rights Reserved 34 Patented by Sun Interpreter based runtime optimization Not part of VM spec, never appear in class files Patched over normal instructions at runtime the first time they are executed Quick Opcodes

35. © 1999, Wen-mei Hwu, All Rights Reserved 35 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

36. © 1999, Wen-mei Hwu, All Rights Reserved 36 Java Objects Outline Classes and Interfaces Polymorphism and Dynamic Method Resolution Method Tables Bytecode Ops for Method Invocation Bytecode Ops for Object Manipulation

37. © 1999, Wen-mei Hwu, All Rights Reserved 37 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)

38. © 1999, Wen-mei Hwu, All Rights Reserved 38 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)

39. © 1999, Wen-mei Hwu, All Rights Reserved 39 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

40. © 1999, Wen-mei Hwu, All Rights Reserved 40 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”

41. © 1999, Wen-mei Hwu, All Rights Reserved 41 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)

42. © 1999, Wen-mei Hwu, All Rights Reserved 42 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.

43. © 1999, Wen-mei Hwu, All Rights Reserved 43 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

44. © 1999, Wen-mei Hwu, All Rights Reserved 44 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

45. © 1999, Wen-mei Hwu, All Rights Reserved 45 Inheritance Hierarchy A class has only one superclass, but may have many ancestors Implementation of a single class can then be treated as multiple interfaces Printer LaserPrinter OfficeMatePlus FaxMachineCopier Class Interface Extends Implements DotMatrix

46. © 1999, Wen-mei Hwu, All Rights Reserved 46 Class/Interface Definition Example // Defer Printer implementation abstract class Printer { abstract void print(); } // Override Printer.print() class DotMatrix extends Printer void print() { // dot matrix printer code... }} // Override Printer.print() class LaserPrinter extends Printer { void print() { // laser printer code... }} // Interfaces contain no code interface Copier { void makeCopies(); } interface FaxMachine { void sendFax(); } // 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... } }

47. © 1999, Wen-mei Hwu, All Rights Reserved 47 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

48. © 1999, Wen-mei Hwu, All Rights Reserved 48 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

49. © 1999, Wen-mei Hwu, All Rights Reserved 49 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() { … } }

50. © 1999, Wen-mei Hwu, All Rights Reserved 50 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

51. © 1999, Wen-mei Hwu, All Rights Reserved 51 Vendor Code Client Code - Evolves Library Routine Iterates through the data structure. Draws each shape in the collection. Queue Binary Tree Hash Table No need to recompile Tree_ Iterator Queue_ Iterator Table_ Iterator (Interface) Stores a collection of shapes in custom data structure Passes the structure to Library Routine Real-World Example Client code has collection of shapes that must be drawn by Vendor code

52. © 1999, Wen-mei Hwu, All Rights Reserved 52 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

53. © 1999, Wen-mei Hwu, All Rights Reserved 53 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)

54. © 1999, Wen-mei Hwu, All Rights Reserved 54 Method Area Method Tables Example print Method Table for OfficeMate Class Java Heap copy fax Code for OfficeMate Code for LaserPrinter Java Stack OfficeMate object Reference to OfficeMate object method table ptr. Fields

55. © 1999, Wen-mei Hwu, All Rights Reserved 55 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

56. © 1999, Wen-mei Hwu, All Rights Reserved 56 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)

57. © 1999, Wen-mei Hwu, All Rights Reserved 57 Method Tables print OfficeMate copy fax Code for OfficeMate Code for LaserPrinter Code for EasyFax print LaserPrinter fax EasyFax print DotMatrix Code for DotMatrix Methods implementing abstract class Printer Methods implementing interface FaxMachine...

58. © 1999, Wen-mei Hwu, All Rights Reserved 58 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

59. © 1999, Wen-mei Hwu, All Rights Reserved 59 Runtime Method Resolution with Compiled Code r1  mem[object_reference] Virtual Call r2  mem[r1+Table_Off_In_Object] call [r2 + Method_Off_In_Table] Interface Call push r1 push InterfaceID call resolveInterfaceOffset (r2  result) call [r2 + Meth_Off_In_Interface] Load object ref Load ptr to meth tbl Indirect call to virtual method Object Ref (Param1) Intrface ID (Param2) Search Method Tbl Offset of interface Indirect call to interface method

60. © 1999, Wen-mei Hwu, All Rights Reserved 60 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

61. © 1999, Wen-mei Hwu, All Rights Reserved 61 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

62. © 1999, Wen-mei Hwu, All Rights Reserved 62 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

63. © 1999, Wen-mei Hwu, All Rights Reserved 63 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

64. © 1999, Wen-mei Hwu, All Rights Reserved 64 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

65. © 1999, Wen-mei Hwu, All Rights Reserved 65 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); } }}

66. © 1999, Wen-mei Hwu, All Rights Reserved 66 Java Runtime Support Outline Execution Models Verification Dynamic Linking Dynamic Extension/Loading Garbage Collection Exception Handling

67. © 1999, Wen-mei Hwu, All Rights Reserved 67 Java Runtime Environment (JRE) beans sqltextrmi securityioawt netutillang Java Virtual Machine Open VMS Java Core API JavaOSWin NTMacSolarisWin 95/98 UnixWareIRIXHP-UXAIX OS/2OthersUXP/DSRISC OSOS/390

68. © 1999, Wen-mei Hwu, All Rights Reserved 68 Java Runtime Overview Java Source Java compiler Bytecode (.class) Class Loader Bytecode verifier Constant Pool Interpreter JIT Memory Manager Security Manager ServicesGUI Operating System Hardware Execution Engine Java VM

69. © 1999, Wen-mei Hwu, All Rights Reserved 69 Basic elements of the JVM Bytecode execution –Interpreter –JIT –Static Compilation –Java Processors

70. © 1999, Wen-mei Hwu, All Rights Reserved 70 Basic elements of the JVM Memory management –garbage collection Class loading Class file and bytecode verification

71. © 1999, Wen-mei Hwu, All Rights Reserved 71 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

72. © 1999, Wen-mei Hwu, All Rights Reserved 72 JIT Compiler/VM Interface JIT makes assumptions about the runtime environment such as: –Code and Data blocks allocated through the VM will stay in place –Every object contains the reference to the class’s method- pointer table

73. © 1999, Wen-mei Hwu, All Rights Reserved 73 Anatomy of a JIT Memory Bytecode importer IR Optimizer Code Generator Linker Bytecode Executor -- Runtime Controller Java Virtual Machine 1 2 3 4 5 6 7 8 9 JIT

74. © 1999, Wen-mei Hwu, All Rights Reserved 74 Anatomy of a JIT 1Runtime controller makes JIT request –passes pointer to memory location of bytecode 2Bytecode importer obtains bytecode and converts it to internal representation (IR) 3The internal representation is then optimized

75. © 1999, Wen-mei Hwu, All Rights Reserved 75 Anatomy of a JIT 4Code generator generates native code from IR 5Code generator requests needed memory from runtime controller –runtime controller passes back pointer to requested memory 6Linker performs traditional linker functions

76. © 1999, Wen-mei Hwu, All Rights Reserved 76 Anatomy of a JIT 7Linker places native code in memory at location specified runtime controller 8Linker provides controller information concerning native code to the runtime controller 9Runtime controller responsible for memory management

77. © 1999, Wen-mei Hwu, All Rights Reserved 77 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

78. © 1999, Wen-mei Hwu, All Rights Reserved 78 HotSpot Summary Garbage Collection –exact generational collector –Non-disruptive Faster thread synchronization –reduction of overhead on allocation and deallocation of thread spaces

79. © 1999, Wen-mei Hwu, All Rights Reserved 79 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

80. © 1999, Wen-mei Hwu, All Rights Reserved 80 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

81. © 1999, Wen-mei Hwu, All Rights Reserved 81 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

82. © 1999, Wen-mei Hwu, All Rights Reserved 82 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

83. © 1999, Wen-mei Hwu, All Rights Reserved 83 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…)

84. © 1999, Wen-mei Hwu, All Rights Reserved 84 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

85. © 1999, Wen-mei Hwu, All Rights Reserved 85 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

86. © 1999, Wen-mei Hwu, All Rights Reserved 86 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) { … } }

87. © 1999, Wen-mei Hwu, All Rights Reserved 87 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 } }

88. © 1999, Wen-mei Hwu, All Rights Reserved 88 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

89. © 1999, Wen-mei Hwu, All Rights Reserved 89 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

90. © 1999, Wen-mei Hwu, All Rights Reserved 90 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

91. © 1999, Wen-mei Hwu, All Rights Reserved 91 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

92. © 1999, Wen-mei Hwu, All Rights Reserved 92 Support for Dynamic Loading in Static Compilers Optimization tradeoffs –Reduces ability to optimize interface calls: can’t establish constant method table offset

93. © 1999, Wen-mei Hwu, All Rights Reserved 93 Garbage Collection Type I: Reference counting Root Set 1.. Heap Space A: B: C: X: D:E: H: G: F: 21 2 1 1 1 11

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

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

96. © 1999, Wen-mei Hwu, All Rights Reserved 96 Garbage Collection Type III: Copying Root Set From Space A: C:B: D: To Space ABCDABDD E:

97. © 1999, Wen-mei Hwu, All Rights Reserved 97 Garbage Collection Type III: Copying (cont.) Garbage Live object time heap allocated size

98. © 1999, Wen-mei Hwu, All Rights Reserved 98 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)

99. © 1999, Wen-mei Hwu, All Rights Reserved 99 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.)

100. © 1999, Wen-mei Hwu, All Rights Reserved 100 Divide heap into generations When current generation fills up, perform copying collection to move the objects to the next older generation (recursive) Garbage Collection Type IV: Generational

101. © 1999, Wen-mei Hwu, All Rights Reserved 101 Short-lived objects quickly freed without recopying long-lived objects –Especially beneficial if long- lived=large and short-lived=small Only need to scan root-set and generations newer than one being collected Garbage Collection Type IV: Generational

102. © 1999, Wen-mei Hwu, All Rights Reserved 102 If objects in older generations point to newer objects –Track these references in separate data structure –Use write-barrier when writing to an older generation (may be significant overhead for storing references) Garbage Collection Type IV: Generational

103. © 1999, Wen-mei Hwu, All Rights Reserved 103 Garbage Collection Type IV: Generational (cont.) Garbage Live object time size First Generation Second Generation Third Generation Recursive collect

104. © 1999, Wen-mei Hwu, All Rights Reserved 104 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

105. © 1999, Wen-mei Hwu, All Rights Reserved 105 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()

106. © 1999, Wen-mei Hwu, All Rights Reserved 106 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.)

107. © 1999, Wen-mei Hwu, All Rights Reserved 107 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

108. © 1999, Wen-mei Hwu, All Rights Reserved 108 VM vs. User Exceptions User thrown exceptions must be explicitly declared and thrown with a throw statement

109. © 1999, Wen-mei Hwu, All Rights Reserved 109 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

110. © 1999, Wen-mei Hwu, All Rights Reserved 110 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

111. © 1999, Wen-mei Hwu, All Rights Reserved 111 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); }

112. © 1999, Wen-mei Hwu, All Rights Reserved 112 // 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(); }

113. © 1999, Wen-mei Hwu, All Rights Reserved 113 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); }... }

114. © 1999, Wen-mei Hwu, All Rights Reserved 114 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; }

115. © 1999, Wen-mei Hwu, All Rights Reserved 115 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)

116. © 1999, Wen-mei Hwu, All Rights Reserved 116 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; }

117. © 1999, Wen-mei Hwu, All Rights Reserved 117 Exception Tables Compiler attaches an exception table to each method with a try block An entry for each exception handler contains:

118. © 1999, Wen-mei Hwu, All Rights Reserved 118 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

119. © 1999, Wen-mei Hwu, All Rights Reserved 119 Finally/Exception Tables Java method void run() throws Exception { int i = 0; try { i++; } finally { i++; } // i always equals 2 here }

120. © 1999, Wen-mei Hwu, All Rights Reserved 120 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 Try block

121. © 1999, Wen-mei Hwu, All Rights Reserved 121 Exception handling considerations Two types –catastrophic: program terminates –non-catastrophic: execution continues after code in catch block is executed

122. © 1999, Wen-mei Hwu, All Rights Reserved 122 Exception handling considerations catastrophic non-catastrophic system user defined state lost state reset state maintained Types of exceptions Types of behavior Effects on program/machine state Restricts code motion

123. © 1999, Wen-mei Hwu, All Rights Reserved 123 Exception Handler Considerations 7 9 8 6 4 5 14 def LV[1] use LV[1] LV[2] = 1 10 LV[2] =10/0 LV[2] alive later Exception handler 4’ Try-block Catch-block

124. © 1999, Wen-mei Hwu, All Rights Reserved 124 Java Core API Overview Set of runtime libraries providing a standard way to access system resources Notable API features –Threads –Serialization –Reflection/Introspection –RMI

125. © 1999, Wen-mei Hwu, All Rights Reserved 125 Some standard API groups –AWT- graphical user interfaces –IO - standard IO –LANG - basic language support –NET - network communications –UTIL - data structure and collections

126. © 1999, Wen-mei Hwu, All Rights Reserved 126 Java Threads Thread class abstracts underlying OS to provide standard interface for multi- threaded execution Synchronization –Each object “owns” a single monitor (lock) –Monitor can be used as in two ways: mutual exclusion or cooperation

127. © 1999, Wen-mei Hwu, All Rights Reserved 127 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

128. © 1999, Wen-mei Hwu, All Rights Reserved 128 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)

129. © 1999, Wen-mei Hwu, All Rights Reserved 129 Cooperative Synchronization object thread1 count=1 thread2 thread3 thread4 monitor wait set object.notify() notifies next waiting thread (thread2) object.wait() relinquishes object’s monitor and enters the wait set allowing thread2 to acquire the monitor heap space (before) object thread2 count=1 thread3 thread4 thread1 monitor wait set heap space (after) (blocked) (runnable) Thread1 executes:

130. © 1999, Wen-mei Hwu, All Rights Reserved 130 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)

131. © 1999, Wen-mei Hwu, All Rights Reserved 131 Serialization Uses Persistent objects - let objects “stick around” between program invocations –Archives and Databases –Checkpoint/Restart to limit data loss or for job-scheduling

132. © 1999, Wen-mei Hwu, All Rights Reserved 132 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

133. © 1999, Wen-mei Hwu, All Rights Reserved 133 Program Instance #2 Program Instance #1 File/Network Stream Serialization Diagram

134. © 1999, Wen-mei Hwu, All Rights Reserved 134 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)

135. © 1999, Wen-mei Hwu, All Rights Reserved 135 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)

136. © 1999, Wen-mei Hwu, All Rights Reserved 136 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)

137. © 1999, Wen-mei Hwu, All Rights Reserved 137 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());...

138. © 1999, Wen-mei Hwu, All Rights Reserved 138 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());...

139. © 1999, Wen-mei Hwu, All Rights Reserved 139 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

140. © 1999, Wen-mei Hwu, All Rights Reserved 140 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)

141. © 1999, Wen-mei Hwu, All Rights Reserved 141 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)

142. © 1999, Wen-mei Hwu, All Rights Reserved 142 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

143. © 1999, Wen-mei Hwu, All Rights Reserved 143 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

144. © 1999, Wen-mei Hwu, All Rights Reserved 144 Visual Development Example Query Viewer Button Register an event listener with Button’s clicked Event (Initialization) Mouse click on Button invokes registered event listeners. The event listener calls Query Viewer’s run method Data Source Query Command # Rows to Fetch properties registered event listeners Run Query

145. © 1999, Wen-mei Hwu, All Rights Reserved 145 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

146. © 1999, Wen-mei Hwu, All Rights Reserved 146 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

147. © 1999, Wen-mei Hwu, All Rights Reserved 147 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

148. © 1999, Wen-mei Hwu, All Rights Reserved 148 Server MachineClient Machine Server VM RMI Diagram Client VM Client Object Proxy Stub Skeleton Object Server Object Network Local Registry Unique Name

149. © 1999, Wen-mei Hwu, All Rights Reserved 149 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

150. © 1999, Wen-mei Hwu, All Rights Reserved 150 Related technologies COM –Microsoft Component Object Model –Packages objects as interoperable “components” provide well defined services visible to independently developed applications –Cross language support

151. © 1999, Wen-mei Hwu, All Rights Reserved 151 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

152. © 1999, Wen-mei Hwu, All Rights Reserved 152 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)

153. © 1999, Wen-mei Hwu, All Rights Reserved 153 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

154. © 1999, Wen-mei Hwu, All Rights Reserved 154 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

155. © 1999, Wen-mei Hwu, All Rights Reserved 155 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)

156. © 1999, Wen-mei Hwu, All Rights Reserved 156 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

157. © 1999, Wen-mei Hwu, All Rights Reserved 157 COM Interfaces (Runtime Spec.) Each interface structure contains: pointer to its offset in the method table pointer back to the original object for internal field access and “recasting” COM Handle fields Interface A Methods. COM Object COM Class Method Table Interface B Interface B Ptr....... Interface B Methods.

158. © 1999, Wen-mei Hwu, All Rights Reserved 158 Java/COM Integration COM interfaces almost identical to Java interfaces at language level Microsoft VM provides bi- directional Java-COM compatibility –Java objects can be exposed as COM objects –COM objects seen as regular Java objects to Java code

159. © 1999, Wen-mei Hwu, All Rights Reserved 159 Java/COM Integration Visual Basic Program COM Interface Regular COM Object MSJAVA.DLL Java Program Java Class w/ COM Attribute (wrapper) Init VM, Create instance of Java COM obj. Regular Java Classes COM Object COM Interface

160. © 1999, Wen-mei Hwu, All Rights Reserved 160 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)

161. © 1999, Wen-mei Hwu, All Rights Reserved 161 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.

162. © 1999, Wen-mei Hwu, All Rights Reserved 162 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

163. © 1999, Wen-mei Hwu, All Rights Reserved 163 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

164. © 1999, Wen-mei Hwu, All Rights Reserved 164 DCOM Architecture Example Microsoft VM DCOM Server Control Manager DCOM Server Control Manager Remote System with DCOM support SCMSCM SCMSCM anonymous object anonymous object COM skeleton COM proxy Java client B Java client A

165. © 1999, Wen-mei Hwu, All Rights Reserved 165 CORBA Overview Standard for distributed, language- independent component interoperability (designed to many types of distributed objects) Interface Definition Language (IDL) language neutral way to specify data types, attributes, operations IDL stored in Interface Repository

166. © 1999, Wen-mei Hwu, All Rights Reserved 166 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

167. © 1999, Wen-mei Hwu, All Rights Reserved 167 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

168. © 1999, Wen-mei Hwu, All Rights Reserved 168 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)

169. © 1999, Wen-mei Hwu, All Rights Reserved 169 C++ ORB C++ ORB Java VM Java ORB Java ORB Remote System (C++ code) IIOP CORBA Architecture IR Java client A client stub server skeleton shared object

170. © 1999, Wen-mei Hwu, All Rights Reserved 170 Java Developments Personal Java Embedded Java Java Card JavaOS

171. © 1999, Wen-mei Hwu, All Rights Reserved 171 Personal Java Target: Network applications on personal consumer devices (e.g. set- top boxes/smart phones) Problem: Core Java API designed to run on desktop machines Solution: Personal Java API - Redefines Core Java API, omitting some features, modifying others.

172. © 1999, Wen-mei Hwu, All Rights Reserved 172 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

173. © 1999, Wen-mei Hwu, All Rights Reserved 173 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

174. © 1999, Wen-mei Hwu, All Rights Reserved 174 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

175. © 1999, Wen-mei Hwu, All Rights Reserved 175 Application Classes Application Classes Embedded Java Classes Embedded Java Classes Hardware Classes Hardware Classes filter and compact code ROMjava.c Static Data Static Data compact data staticData.c Developer Embedded Java Vendor Native compiler native linker ROMlet staticData.o ROMjava.o native methods native methods Virtual Machine Virtual Machine OS image Embedded Java Components

176. © 1999, Wen-mei Hwu, All Rights Reserved 176 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

177. © 1999, Wen-mei Hwu, All Rights Reserved 177 Personal Java Key Points Like standard Java, designed to run arbitrary applets downloaded across a network (runs most general- purpose applets) Provides a well-defined subset of API features; throws exception if the applications requests an unsupported operation

178. © 1999, Wen-mei Hwu, All Rights Reserved 178 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

179. © 1999, Wen-mei Hwu, All Rights Reserved 179 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

180. © 1999, Wen-mei Hwu, All Rights Reserved 180 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)

181. © 1999, Wen-mei Hwu, All Rights Reserved 181 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)

182. © 1999, Wen-mei Hwu, All Rights Reserved 182 JavaCard Split VM Off-card –Class loading, linking, resolution –Verification –Bytecode optimization and conversions On-card –Bytecode execution

183. © 1999, Wen-mei Hwu, All Rights Reserved 183 Java Card Applets Additional framework for card applets –Communications protocol w/ terminal –File system compatible w/ industry standard –Cryptographic functions

184. © 1999, Wen-mei Hwu, All Rights Reserved 184 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

185. © 1999, Wen-mei Hwu, All Rights Reserved 185 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

186. © 1999, Wen-mei Hwu, All Rights Reserved 186 Java Card Considerations Memory space is limited –Applets should create and initialize all necessary objects at installation to avoid hitting memory limit at runtime

187. © 1999, Wen-mei Hwu, All Rights Reserved 187 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)

188. © 1999, Wen-mei Hwu, All Rights Reserved 188 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

189. © 1999, Wen-mei Hwu, All Rights Reserved 189 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)

190. © 1999, Wen-mei Hwu, All Rights Reserved 190 JavaOS Runtime Core Java Classes Java Language Classes AWT Classes I/O Classes Java Virtual Machine AWT Support I/O Support JavaOS Device Drivers JavaOS Platform Interface JavaOS Microkernel JavaOS Components

191. © 1999, Wen-mei Hwu, All Rights Reserved 191 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.

192. © 1999, Wen-mei Hwu, All Rights Reserved 192 Java Programming Bruce Eckel. Thinking in Java. Prentice Hall, 1998. http://www.BruceEckel.com David Flanagan. Java in a Nutshell. O'Reilly, 1997.

193. © 1999, Wen-mei Hwu, All Rights Reserved 193 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

194. © 1999, Wen-mei Hwu, All Rights Reserved 194 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.

195. © 1999, Wen-mei Hwu, All Rights Reserved 195 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.

196. © 1999, Wen-mei Hwu, All Rights Reserved 196 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/

197. © 1999, Wen-mei Hwu, All Rights Reserved 197 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

198. © 1999, Wen-mei Hwu, All Rights Reserved 198 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/