Java Virtual Machine: VM Architecture, Software Architecture, Implementations, and Application Progr...
Download
1 / 198

Wen-mei Hwu Department of ECE University of Illinois - PowerPoint PPT Presentation


  • 50 Views
  • Uploaded on

Java Virtual Machine: VM Architecture, Software Architecture, Implementations, and Application Programming Interfaces. Wen-mei Hwu Department of ECE University of Illinois. Objective of the Course. In-depth understanding of unique aspects of Java-based systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Wen-mei Hwu Department of ECE University of Illinois' - adena-cantrell


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Java Virtual Machine: VM Architecture, Software Architecture, Implementations, and Application Programming Interfaces

Wen-mei Hwu

Department of ECE

University of Illinois


Objective of the course
Objective of the Course Architecture, Implementations, and Application Programming Interfaces

  • In-depth understanding of unique aspects of Java-based systems

    • Benefit of Java language features for various applications

    • Complexities of the Java Bytecode architecture

    • Functionalities of the Java API and runtime


Outline
Outline Architecture, Implementations, and Application Programming Interfaces

  • Introduction

  • Basic Bytecode Architecture

  • Java Objects

  • Java Runtime

  • Java Core API

  • Related Technologies

  • Java Related Developments


Java security
Java Security Architecture, Implementations, and Application Programming Interfaces

  • Bytecode Level

    • Disallows pointer manipulation

    • Provides array bounds checking

    • Checks for NULL references (pointers)

    • Eliminates illegal type casting


Java security1
Java Security Architecture, Implementations, and Application Programming Interfaces

  • API Level

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

    • Authentication: verify that bytecode is from a trusted vendor


Java portability mobility
Java Portability/Mobility Architecture, Implementations, and Application Programming Interfaces

  • Bytecode Level

    • Binary compatibility: abstracts machine architecture and compiler

    • Standard module format and compact representation

    • Dynamic linking and loading


Java portability mobility1
Java Portability/Mobility Architecture, Implementations, and Application Programming Interfaces

  • API Level

    • Operating system abstraction

    • Consistent support for

      • Threads

      • I/O and Network interface

      • Database Interface

      • Graphical User interface


Development environment
Development Environment Architecture, Implementations, and Application Programming Interfaces

  • Language features

    • Automatic memory management

    • Structured exception handling

    • Object-oriented design


Development environment1
Development Environment Architecture, Implementations, and Application Programming Interfaces

  • Modular development and 3rd-party software components

    • Standard, dynamically linked modules

    • Packages (related class file naming)

      • Avoid naming conflicts

      • Control access between modules


Key application areas
Key Application Areas Architecture, Implementations, and Application Programming Interfaces

  • Network-based devices

    • Mobility - applet downloading and software agents

    • Portability - code server has no knowledge of client platform

    • Security - code cannot be trusted


Key application areas1
Key Application Areas Architecture, Implementations, and Application Programming Interfaces

  • Distributed applications

    • Common development environment across tiers

    • Same code can run on all machines

    • Software can be repartitioned as hardware/requirements change


Database application development
Database Application Development Architecture, Implementations, and Application Programming Interfaces

  • Can safely extend server software with Java bytecode

    • Traditional approach: may crash server or corrupt database

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


Database application development1
Database Application Development Architecture, Implementations, and Application Programming Interfaces

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

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

  • Run server on multiple platforms/easy migration


Incorporating object data types
Incorporating Object Data Types Architecture, Implementations, and Application Programming Interfaces

  • Objects can be serialized and delivered to client

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

    • Different situations may call for either approach

  • Bytecode can be loaded directly from the database


Database example
Database Example Architecture, Implementations, and Application Programming Interfaces

  • Each employee record contains a Java address object

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

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


Database example1
Database Example Architecture, Implementations, and Application Programming Interfaces

  • Database designers can exploit inheritance to handle address idiosyncrasies

    • Subclasses of type US_Address and CanadianAddress

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


Database example2
Database Example Architecture, Implementations, and Application Programming Interfaces

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’))


Database example3
Database Example Architecture, Implementations, and Application Programming Interfaces

  • Query cities and short zip codes

    • Method to calculate short zip code runs on server

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


Database example4
Database Example Architecture, Implementations, and Application Programming Interfaces

  • 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()


Challenges presented by java
Challenges Presented By Java Architecture, Implementations, and Application Programming Interfaces

  • Translation to native architecture

    • Instruction set translation

    • Stack based to register based conversion

    • Dynamic Linking - delay translation or manage binary dependencies


Challenges presented by java1
Challenges Presented By Java Architecture, Implementations, and Application Programming Interfaces

  • Barriers to optimization

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

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

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


Challenges presented by java2
Challenges Presented By Java Architecture, Implementations, and Application Programming Interfaces

  • Security features add overhead

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

    • Additional code and control flow to protect resource access


Bytecode architecture overview
Bytecode Architecture Overview Architecture, Implementations, and Application Programming Interfaces

  • 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


Bytecode architecture overview1
Bytecode Architecture Overview Architecture, Implementations, and Application Programming Interfaces

  • Extensive support for Java Language and Dynamic Linking

    • Object manipulation instructions

    • Method invocation instructions

    • Exception handling support


Bytecode architecture overview2
Bytecode Architecture Overview Architecture, Implementations, and Application Programming Interfaces

  • Opcode space

    • 202 assigned, 25 quick, 3 reserved

  • Load-store stack architecture

    • avoid register file size assumption

    • smaller code size

      • 73.3% of the assigned opcodes are a single byte


Stack computation model
Stack Computation Model Architecture, Implementations, and Application Programming Interfaces

Example: add

Translated code

push A

push B

r2 ¬ pop(B)

r1¬ pop(A)

r3 ¬ r1+r2

push r3

Stack operation

push A

push B

add


Bytecode modules class files
Bytecode Modules (Class Files) Architecture, Implementations, and Application Programming Interfaces

  • Java language compiler produces separate module (class file) for each class defined in program

  • All references across classes (and most within a class)

    • compiled as symbolic references

    • stored in a data structure inside class file ( constant pool)


Bytecode modules class files1
Bytecode Modules (Class Files) Architecture, Implementations, and Application Programming Interfaces

  • Bytecode with operands (27.7% of total assigned opcodes)

    • typically indexes into the constant pool or local variable table


Bytecode operands
Bytecode operands Architecture, Implementations, and Application Programming Interfaces

  • As VM executes a method its stack frame holds a pointer to the constant pool of the method’s class

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


Simple example
Simple example Architecture, Implementations, and Application Programming Interfaces

Invokevirtual 0x0005

Constant Pool

...

...

Method ref

5

Constant pool

...

...

8

class ref

Stack frame

...

Name & type

a

...

d

“add”

...

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

11


Bytecode operation types
Bytecode operation types Architecture, Implementations, and Application Programming Interfaces

  • Stack Manipulations

    • push, pop, duplicate, swap

  • Local Variable accessing

    • load, store

  • Arrays

    • create, store, retrieve


Bytecode operation types1
Bytecode operation types Architecture, Implementations, and Application Programming Interfaces

  • Objects

    • create, access, set

  • Arithmetic and Type Conversion

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


Bytecode operation types2
Bytecode operation types Architecture, Implementations, and Application Programming Interfaces

  • Control Flow and Exceptions

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

  • Method Calls and Returns

    • virtual, special, static, interface, returns


Quick opcodes
Quick Opcodes Architecture, Implementations, and Application Programming Interfaces

  • 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 opcodes1
Quick Opcodes Architecture, Implementations, and Application Programming Interfaces

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

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


Java objects outline
Java Objects Outline Architecture, Implementations, and Application Programming Interfaces

  • Classes and Interfaces

  • Polymorphism and Dynamic Method Resolution

  • Method Tables

  • Bytecode Ops for Method Invocation

  • Bytecode Ops for Object Manipulation


Language terms
Language Terms Architecture, Implementations, and Application Programming Interfaces

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

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

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

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


Language terms1
Language Terms Architecture, Implementations, and Application Programming Interfaces

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


Basic java types
Basic Java Types Architecture, Implementations, and Application Programming Interfaces

  • Primitive Types

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

    • range of values for each type constant across platforms

  • Reference Types (non-primitive)

    • Declare pointers to objects on the Java Heap


Reference types
Reference Types Architecture, Implementations, and Application Programming Interfaces

  • Java language requires that each reference variable has a declared type (statically typed)

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

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


Reference types1
Reference Types Architecture, Implementations, and Application Programming Interfaces

  • Interface: Set of guaranteed method declarations without any implementation

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

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


Class hierarchy
Class Hierarchy Architecture, Implementations, and Application Programming Interfaces

  • A class may extend one other class, its superclass. A class inherits the fields and methods of its superclass including their implementation.

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


Extending classes method overriding
Extending Classes: Method Overriding Architecture, Implementations, and Application Programming Interfaces

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

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


Abstract classes
Abstract Classes Architecture, Implementations, and Application Programming Interfaces

  • A class may defer implementing a method by declaring it abstract

  • A class with abstract methods cannot be instantiated

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


Inheritance hierarchy
Inheritance Hierarchy Architecture, Implementations, and Application Programming Interfaces

Printer

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

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

Class

Interface

DotMatrix

LaserPrinter

Copier

FaxMachine

Extends

Implements

OfficeMatePlus


Class interface definition example
Class/Interface Definition Example Architecture, Implementations, and Application Programming Interfaces

// 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 ... }

}

// 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 ...

}}


Dynamic method resolution
Dynamic Method Resolution Architecture, Implementations, and Application Programming Interfaces

  • Dynamic resolution ensures that the correct code will be invoked based on the object’s runtime class

  • Interface Calls

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


Dynamic method resolution1
Dynamic Method Resolution Architecture, Implementations, and Application Programming Interfaces

  • Virtual Calls

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


Revisiting class interface example
Revisiting Class/Interface Example Architecture, Implementations, and Application Programming Interfaces

// More office equipment

class QuickCopier implements Copier {

public void

makeCopies() { … }

}

class EasyFax

implements FaxMachine {

public void

sendFax() { … }

}

// 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(); }

}


Revisiting class interface example1
Revisiting Class/Interface Example Architecture, Implementations, and Application Programming Interfaces

// 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

// 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);


Real world example
Real-World Example Architecture, Implementations, and Application Programming Interfaces

  • Client code has collection of shapes that must be drawn by Vendor code

Vendor Code

Client Code - Evolves

Queue_

Iterator

Library Routine

Iterates through the data structure.

Draws each shape in the collection.

Stores a collection of shapes in custom data structure

Passes the structure to Library Routine

Queue

Tree_

Iterator

Iterator

Binary Tree

(Interface)

Table_

Iterator

Hash Table

No need to recompile


Method tables
Method Tables Architecture, Implementations, and Application Programming Interfaces

  • For dynamic method resolution, every class maintains a table containing an entry for each non-static method

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


Method tables1
Method Tables Architecture, Implementations, and Application Programming Interfaces

  • Each entry in the method table points to (depending on implementation):

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

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


Method tables example
Method Tables Example Architecture, Implementations, and Application Programming Interfaces

Java Stack

Reference to

OfficeMate object

Method Area

Java Heap

Method Table for

OfficeMate Class

Code for

LaserPrinter

OfficeMate object

print

method table ptr.

copy

Fields

Code for

OfficeMate

fax


Constructing method tables
Constructing Method Tables Architecture, Implementations, and Application Programming Interfaces

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

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


Constructing method tables1
Constructing Method Tables Architecture, Implementations, and Application Programming Interfaces

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

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


Method Tables Architecture, Implementations, and Application Programming Interfaces

Methods implementing abstract class Printer

Methods implementing interface FaxMachine

EasyFax

DotMatrix

LaserPrinter

OfficeMate

...

...

...

...

fax

print

print

print

copy

fax

Code for

EasyFax

Code for

DotMatrix

Code for

LaserPrinter

Code for

OfficeMate


Runtime method resolution with compiled code
Runtime Method Resolution with Compiled Code Architecture, Implementations, and Application Programming Interfaces

  • Resolved Interface Call

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

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


Runtime method resolution with compiled code1
Runtime Method Resolution with Compiled Code Architecture, Implementations, and Application Programming Interfaces

r1 ¬ mem[object_reference]

Virtual Call

r2 ¬ mem[r1+Table_Off_In_Object]

call [r2 + Method_Off_In_Table]

Interface Call

push r1

push InterfaceID

call resolveInterfaceOffset

(r2 ¬ result)

call [r2 + Meth_Off_In_Interface]

Load object ref

Load ptr to meth tbl

Indirect call to virtual method

Object Ref (Param1)

Intrface ID (Param2)

Search Method Tbl

Offset of interface

Indirect call to interface method


Static optimization for interface calls
Static Optimization for Architecture, Implementations, and Application Programming InterfacesInterface Calls

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

  • Compiler must have advance access to every class potentially loaded

    • No dynamic linking


Problems with virtual calls
Problems with Virtual Calls Architecture, Implementations, and Application Programming Interfaces

  • Call Overhead: Virtual Calls require at least a memory load followed by an indirect call

  • Prevents ILP

    • Current branch prediction does not work well on indirect calls

    • Unable to inline or perform interprocedural analysis


Optimizing virtual calls
Optimizing Virtual Calls Architecture, Implementations, and Application Programming Interfaces

  • Type Inference

    • Class hierarchy analysis (prohibits dynamic loading)

    • Type-aware dataflow analysis

  • Type prediction

    • Based on profile information

    • Need mechanism to recover from incorrect prediction


Check cast details
Check Cast Details Architecture, Implementations, and Application Programming Interfaces

  • Inserted by compiler at explicit casts to verify that the type cast is safe:

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

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

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


Instance of details
Instance Of Details Architecture, Implementations, and Application Programming Interfaces

  • Used when programmer requests runtime type identification with the “instanceof” language keyword

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

  • Uses same rules as CheckCast

  • Returns ZERO on failure, ONE on success


Checkcast instanceof example
CheckCast/InstanceOf Example Architecture, Implementations, and Application Programming Interfaces

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);

}

}}


Java runtime support outline
Java Runtime Support Outline Architecture, Implementations, and Application Programming Interfaces

  • Execution Models

  • Verification

  • Dynamic Linking

  • Dynamic Extension/Loading

  • Garbage Collection

  • Exception Handling


Java runtime environment jre
Java Runtime Environment (JRE) Architecture, Implementations, and Application Programming Interfaces

Java Core API

beans

rmi

text

sql

Java Virtual

Machine

awt

security

io

net

util

lang

JavaOS

Win 95/98

Solaris

Mac

Win NT

AIX

HP-UX

IRIX

Open VMS

UnixWare

OS/2

OS/390

RISC OS

UXP/DS

Others


Java runtime overview

Class Architecture, Implementations, and Application Programming Interfaces

Loader

Bytecode

verifier

Services

GUI

Operating System

Hardware

Java Runtime Overview

Java VM

Java

Source

Constant

Pool

Memory

Manager

Java

compiler

Execution Engine

JIT

Interpreter

Security

Manager

Bytecode

(.class)


Basic elements of the jvm
Basic elements of the JVM Architecture, Implementations, and Application Programming Interfaces

  • Bytecode execution

    • Interpreter

    • JIT

    • Static Compilation

    • Java Processors


Basic elements of the jvm1
Basic elements of the JVM Architecture, Implementations, and Application Programming Interfaces

  • Memory management

    • garbage collection

  • Class loading

  • Class file and bytecode verification


Jit compiler vm interface
JIT Compiler/VM Interface Architecture, Implementations, and Application Programming Interfaces

  • Compilation Unit for the JIT is a single method

    • JIT may request additional methods for inlining

  • VM decides which methods to compile


Jit compiler vm interface1
JIT Compiler/VM Interface Architecture, Implementations, and Application Programming Interfaces

  • JIT makes assumptions about the runtime environment such as:

    • Code and Data blocks allocated through the VM will stay in place

    • Every object contains the reference to the class’s method-pointer table


Anatomy of a jit
Anatomy of a JIT Architecture, Implementations, and Application Programming Interfaces

Java Virtual Machine

1

Bytecode

Executor

--

Runtime Controller

Bytecode

importer

IR

Optimizer

2

3

4

5

Code

Generator

8

Linker

6

JIT

9

7

Memory


Anatomy of a jit1
Anatomy of a JIT Architecture, Implementations, and Application Programming Interfaces

  • Runtime controller makes JIT request

    • passes pointer to memory location of bytecode

  • Bytecode importer obtains bytecode and converts it to internal representation (IR)

  • The internal representation is then optimized


Anatomy of a jit2
Anatomy of a JIT Architecture, Implementations, and Application Programming Interfaces

  • Code generator generates native code from IR

  • Code generator requests needed memory from runtime controller

    • runtime controller passes back pointer to requested memory

  • Linker performs traditional linker functions


Anatomy of a jit3
Anatomy of a JIT Architecture, Implementations, and Application Programming Interfaces

  • Linker places native code in memory at location specified runtime controller

  • Linker provides controller information concerning native code to the runtime controller

  • Runtime controller responsible for memory management


Hotspot summary
HotSpot Summary Architecture, Implementations, and Application Programming Interfaces

  • JIT with C-quality code generator

    • much faster byetcode execution

    • JIT optimizes the small percentage of the code that accounts for the majority of the execution time

    • allows more time for more aggressive optimizations

  • Adaptive optimization and aggressive inlining

    • uses runtime profiling data


Hotspot summary1
HotSpot Summary Architecture, Implementations, and Application Programming Interfaces

  • Garbage Collection

    • exact generational collector

    • Non-disruptive

  • Faster thread synchronization

    • reduction of overhead on allocation and deallocation of thread spaces


Verification
Verification Architecture, Implementations, and Application Programming Interfaces

  • 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


Verification1
Verification Architecture, Implementations, and Application Programming Interfaces

  • VM rules for properly formed bytecode

    • Valid Opcodes

    • Operand stack always contains the same number and type of items no matter which execution path is taken


Dynamic linking
Dynamic Linking Architecture, Implementations, and Application Programming Interfaces

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

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

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


Dynamic linking1
Dynamic Linking Architecture, Implementations, and Application Programming Interfaces

  • VM may throw a linkage exceptions at runtime when a referenced class, method, or field cannot be located or has conflicting access specifiers

    • Not thrown until bytecode that indexes the reference is actively used


Static resolution example
Static Resolution Example Architecture, Implementations, and Application Programming Interfaces

  • To resolve static field reference the VM checks:

    • referenced class exists and this class has permission to access it

    • named field exists in referenced class, has expected type, is static not instance, and this class has permission to access the field

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


Dynamic extension loading
Dynamic Extension/Loading Architecture, Implementations, and Application Programming Interfaces

  • Load class at runtime that compiler does not have access to at compile-time

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

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


Dynamic extension loading1
Dynamic Extension/Loading Architecture, Implementations, and Application Programming Interfaces

  • Second, instructing the newly loaded class to create a new instance,

  • Third, then either:

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

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


Dynamic loading example
Dynamic Loading Example Architecture, Implementations, and Application Programming Interfaces

interface QueryDriver {

String processQuery(String command);

}

// This class is unknown at compile time

class DynamicDriver implements QueryDriver {

public String processQuery(String command) { … }

}


class Architecture, Implementations, and Application Programming InterfacesDynamicLoader {

void run(String driver_name) throws

ClassNotFoundException, IllegalAccessException,

InstantiationException {

// Instruct class loader to create named class

Class driver_class = Class.forName(driver_name);

try {

// Create a new instance of the driver

// class, cast to QueryDriver

QueryDriver driver = (QueryDriver)

driver_class.newInstance();

String command = getInput();

// If cast succeeded, driver implements processQuery

String result = driver.processQuery(command);

} catch(ClassCastException e) { …

// Invalid Driver }

}

}


Custom classloaders
Custom Classloaders Architecture, Implementations, and Application Programming Interfaces

  • Developers can extend the built-in class loader architecture to load bytecode from alternative sources:

    • Download across the network

    • Query from a database

    • Extract from binary formats other than standard class file

    • Compile/compute bytecode on the fly


Custom classloaders1
Custom Classloaders Architecture, Implementations, and Application Programming Interfaces

  • Example: Applets

    • Web browser starts an appletviewer Java program in a frame

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

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


Support for dynamic loading in static compilers
Support for Dynamic Loading in Static Compilers Architecture, Implementations, and Application Programming Interfaces

  • 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


Support for dynamic loading in static compilers1
Support for Dynamic Loading in Static Compilers Architecture, Implementations, and Application Programming Interfaces

  • 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


Support for dynamic loading in static compilers2
Support for Dynamic Loading in Static Compilers Architecture, Implementations, and Application Programming Interfaces

  • Optimization tradeoffs

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


Garbage collection type i reference counting
Garbage Collection Architecture, Implementations, and Application Programming InterfacesType I: Reference counting

Heap Space

A:

2

X:

B:

Root

Set

1

..

..

1

C:

1

D:

E:

1

1

F:

H:

G:

1

2

1


Garbage collection type i reference counting cont
Garbage Collection Architecture, Implementations, and Application Programming InterfacesType I: Reference counting (cont.)

Heap Space

A:

1

X:

B:

Root

Set

1

..

..

1

C:

1

A-B-C

form

a circle

D:

E:

1

1

F:

H:

G:

1

2

1


Garbage collection type ii marking sweeping

- Architecture, Implementations, and Application Programming Interfaces

-

-

-

-

F

-

-

-

-

-

-

X

-

B

-

D

G

-

A

-

-

-

-

H

-

C

-

F

-

-

-

Garbage CollectionType II: Marking & Sweeping

Heap Space

A:

X:

B:

Root

Set

..

..

..

C:

D:

E:

Mark Bits

F:

G:

H:


Garbage Collection Architecture, Implementations, and Application Programming InterfacesType III: Copying

From Space

To Space

A:

B:

C:

E:

Root

Set

D:

A

A

B

B

C

D

D

D


Garbage Collection Architecture, Implementations, and Application Programming InterfacesType III: Copying (cont.)

heapallocated

size

Garbage

Live object

time


G c optimizations
G.C. Optimizations Architecture, Implementations, and Application Programming Interfaces

  • G.C. Prevention

    • heap objects live analysis

      • insert explicit “free”

      • allocate local objects from stack

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


G c optimizations1
G.C. Optimizations Architecture, Implementations, and Application Programming Interfaces

  • 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.)


Garbage collection type iv generational
Garbage Collection Architecture, Implementations, and Application Programming InterfacesType IV: Generational

  • 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 generational1

Short-lived objects quickly freed without recopying long-lived objects

Especially beneficial if long-lived=large and short-lived=small

Only need to scan root-set and generations newer than one being collected

Garbage CollectionType IV: Generational


Garbage collection type iv generational2

If objects in older generations point to newer objects long-lived objects

Track these references in separate data structure

Use write-barrier when writing to an older generation (may be significant overhead for storing references)

Garbage CollectionType IV: Generational


Garbage Collection long-lived objectsType IV: Generational (cont.)

size

First Generation

Recursive collect

Second Generation

Garbage

Third Generation

Live object

time


Exception handling
Exception Handling long-lived objects

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

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


Exception handling1
Exception Handling long-lived objects

  • While the type of exception thrown selects the handler, information about the error is stored inside the exception

    • exception is an object in Java

  • All exception classes derived from Throwable which supports the methods:

    • String getMessage()

    • void printStackTrace()


Vm vs user exceptions
VM vs. User Exceptions long-lived objects

  • VM thrown exceptions can implicitly occur almost anywhere

    • Derived from Error, need system attention

      • Virtual Machine Errors (OutOfMemory, etc.)

      • Dynamic Linking (ClassFormatError, etc.)


Vm vs user exceptions1
VM vs. User Exceptions long-lived objects

  • VM thrown exceptions

    • Derived from RuntimeException, can be handled by the user

      • Array Bounds Checking

      • Null Pointer Checking

      • Explicit Type Casting

      • Security Checks


Vm vs user exceptions2
VM vs. User Exceptions long-lived objects

  • User thrown exceptions must be explicitly declared and thrown with a throw statement


Why use exception handling
Why use Exception Handling? long-lived objects

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

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


Why use exception handling1
Why use Exception Handling? long-lived objects

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

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


Java exceptions example code

class long-lived objectsDatabaseException 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);

}

}

Java Exceptions Example Code


// User Code: display name in box long-lived objects

// 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();

}


Typical c error handling
Typical C Error Handling long-lived objects

// 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);

} ...

}


Typical c error handling1
Typical C Error Handling long-lived objects

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;

}


Finally clause
Finally Clause long-lived objects

  • Code inside a finally block is executed regardless of how control flow exits a try block

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

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


Finally clause1
Finally Clause long-lived objects

// 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;

}


Exception tables
Exception Tables long-lived objects

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

  • An entry for each exception handler contains:


Exception tables1
Exception Tables long-lived objects

  • When exception occurs the VM checks

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

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


Finally exception tables
Finally/Exception Tables long-lived objects

Java method

void run() throws Exception {

int i = 0;

try {

i++;

}

finally {

i++;

}

// i always equals 2 here

}


Compiled Bytecode long-lived objects

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


Exception handling considerations
Exception handling considerations long-lived objects

  • Two types

    • catastrophic: program terminates

    • non-catastrophic: execution continues after code in catch block is executed


Exception handling considerations1
Exception handling considerations long-lived objects

Types of

exceptions

system

user defined

Types

of

behavior

catastrophic

non-catastrophic

Effects

on

program/machine

state

state lost

state maintained

state reset

Restricts code motion


Exception Handler Considerations long-lived objects

def LV[1]

use LV[1]

4’

Try-block

Catch-block

4

Exception

handler

5

6

14

use LV[1]

LV[2] = 1

LV[2] =10/0

8

7

9

use LV[1]

LV[2] alive later

10


Java core api overview
Java Core API Overview long-lived objects

  • Set of runtime libraries providing a standard way to access system resources

  • Notable API features

    • Threads

    • Serialization

    • Reflection/Introspection

    • RMI


Some standard api groups
Some standard API groups long-lived objects

  • AWT- graphical user interfaces

  • IO - standard IO

  • LANG - basic language support

  • NET - network communications

  • UTIL - data structure and collections


Java threads
Java Threads long-lived objects

  • Thread class abstracts underlying OS to provide standard interface for multi-threaded execution

  • Synchronization

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

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


Mutual exclusion
Mutual Exclusion long-lived objects

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

  • Compiler inserts monitorenter and monitorexit bytecode instructions

  • Methods declared synchronized do not require additional bytecode instructions


Thread cooperation
Thread Cooperation long-lived objects

  • wait() method - relinquish monitor but remain in the “wait set”

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

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


Cooperative synchronization
Cooperative Synchronization long-lived objects

heap space

(before)

heap space

(after)

Thread1 executes:

object.notify()

notifies next waiting thread (thread2)

object.wait()

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

object

object

monitor

monitor

thread1

count=1

thread2

count=1

(runnable)

(runnable)

wait set

wait set

thread2

thread3

thread4

thread3

thread4

thread1

(blocked)

(blocked)


Serialization
Serialization long-lived objects

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

    • Except transient or static fields or non-serializable objects

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


Serialization uses
Serialization Uses long-lived objects

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

    • Archives and Databases

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


Serialization uses1
Serialization Uses long-lived objects

  • Transfer objects - for communication or replication

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

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


Serialization diagram
Serialization Diagram long-lived objects

File/Network Stream

Program Instance #2

Program Instance #1


Reflection api
Reflection API long-lived objects

  • 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)


Reflection api1
Reflection API long-lived objects

  • Support for dynamically invoking the class members

    Object Field.get (Object obj)

    void Field.set (Object obj, Object value)

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

    Object Constructor.newInstance(Object[] initargs)


Reflection api2
Reflection API long-lived objects

  • Why Reflection?

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

    • Facilitate component software (JavaBeans)


Using reflection
Using Reflection long-lived objects

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

...

Dog corky = new Dog();

corky.fetch(new Stick());

corky.chew(new Frisbee());

...

interface Toy {}

class Frisbee

implements Toy {}

class Stick

implements Toy {}

class Dog {

public void

fetch(Toy toy) {...}

public void

chew(Toy toy) {...}

}


Using reflection1
Using Reflection long-lived objects

...

Dog corky = new Dog();

playWithDog(corky, “fetch”, new Stick());

playWithDog(corky, “chew”, new Frisbee());

...

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);

}


Javabeans
JavaBeans long-lived objects

  • 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


Javabeans1
JavaBeans long-lived objects

  • Properties: Allow configuration of the internal state of the bean

  • Methods: Other components can invoke services provided by bean

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


Visual development
Visual Development long-lived objects

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

  • Import 3rd party beans

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


Visual development1
Visual Development long-lived objects

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

  • Save custom state as pre-initialized beans using serialization

  • Looks like standard Java program to end user


Visual development example
Visual Development Example long-lived objects

  • Creating a graphical interface for database queries

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

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


Visual development example1
Visual Development Example long-lived objects

registered

event listeners

Button

Register an event listener with Button’s clicked Event (Initialization)

Run Query

Mouse click on Button invokes registered event listeners. The event listener calls Query Viewer’s run method

Query Viewer

properties

Data Source

Query Command

# Rows to Fetch


Rmi remote method invocation
RMI - Remote Method Invocation long-lived objects

  • Send messages to Java objects running on another machine (distributed objects)

  • Similar to RPC, but object-based

  • RMI can also load code from server

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


Rmi communication objects
RMI Communication objects long-lived objects

  • Client side: stub object takes place of server object (proxy)

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

  • Interfaces create abstraction between communication object and actual remote object


Using rmi
Using RMI long-lived objects

  • 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


Rmi diagram
RMI Diagram long-lived objects

Client Machine

Server Machine

Server VM

Client VM

Skeleton

Object

Client

Object

Proxy

Stub

Network

Local

Registry

Server

Object

Unique Name


Rmi considerations
RMI Considerations long-lived objects

  • Arguments must be marshaled (converted to binary stream to send across the network)

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

  • Reference counting tracks live references across virtual machines


Related technologies
Related technologies long-lived objects

  • COM

    • Microsoft Component Object Model

    • Packages objects as interoperable “components”

      • provide well defined services

      • visible to independently developed applications

    • Cross language support


Related technologies1
Related technologies long-lived objects

  • DCOM

    • Extension of COM to allow distributed components

    • Alternative to RMI

  • CORBA

    • OMG spec. for cross-language distributed object infrastructure

    • Alternative to RMI and DCOM


Com details
COM Details long-lived objects

  • MIDL describes COM classes, interfaces, and methods

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

    • Standard method table layout

    • Standard data format for parameters

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


Com details1
COM Details long-lived objects

  • Components can reside in separate binaries (DLL/EXE)

  • Dynamic linking allows independent component evolution

  • Components registered by the OS

    • GUID and name identifies type

    • Type library available to all applications


Com at the language level
COM at the Language Level long-lived objects

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

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


Com at the language level1
COM at the Language Level long-lived objects

  • Reference object model (like Java), programmer passes object handles

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

  • All interfaces derived from IUnknown

    • Safe casting to more sophisticated interfaces (QueryInterface)

    • Reference Counting (AddRef/Release)


Com interfaces runtime spec
COM Interfaces (Runtime Spec.) long-lived objects

  • COM maintains separate method table pointers for each interface

  • Subsequent interface calls are quick by retaining interface pointer

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

  • No direct field access


Com interfaces runtime spec1
COM Interfaces (Runtime Spec.) long-lived objects

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 Class

Method Table

COM Object

COM Handle

fields

Interface A

Methods

.

.

Interface A

Interface B

Interface B

Methods

.

.

.

.

.

Interface B Ptr.


Java com integration
Java/COM Integration long-lived objects

  • COM interfaces almost identical to Java interfaces at language level

  • Microsoft VM provides bi-directional Java-COM compatibility

    • Java objects can be exposed as COM objects

    • COM objects seen as regular Java objects to Java code


Java com integration1
Java/COM Integration long-lived objects

Visual Basic

Program

Java

Program

Regular

Java

Classes

Java Class w/

COM Attribute

(wrapper)

COM

Interface

Init VM,

Create instance

of Java COM obj.

COM

Interface

Regular

COM Object

MSJAVA.DLL

COM Object


Java vs com
Java vs. COM long-lived objects

  • Runtime binary standard

    • COM - Defines method table layout and standard data types

    • Java - Classes distributed in standard format then dynamically linked (each VM may determine runtime memory layout independently)


Java vs com1
Java vs. COM long-lived objects

  • Published type information

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

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


Dcom overview
DCOM Overview long-lived objects

  • Distributed COM objects

  • DCOM object can replace a COM object without recompiling code

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

  • Integrates with Java via COM integration


Dcom architecture
DCOM Architecture long-lived objects

  • OS maintained type library analogous to RMI registry

  • To establish communications:

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

    • Receive an interface pointer representing the new object

  • Specific objects assigned a moniker


Dcom architecture example
DCOM Architecture Example long-lived objects

Microsoft VM

Remote System with DCOM support

DCOM

Server

Control

Manager

S

C

M

Java client A

COM proxy

COM skeleton

anonymous

object

Java client B

COM proxy

COM skeleton

anonymous

object


Corba overview
CORBA Overview long-lived objects

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

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

  • IDL stored in Interface Repository


Corba overview1
CORBA Overview long-lived objects

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

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


Corba comparison
CORBA Comparison long-lived objects

  • Like RMI and DCOM, stubs/skeletons abstract network communications

  • Similar in scope to DCOM

  • Some basic differences:

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

    • CORBA requires 3rd party ORB, many alternatives


Corba vs rmi
CORBA vs. RMI long-lived objects

  • 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)


Corba architecture
CORBA Architecture long-lived objects

Java VM

Remote System (C++ code)

C++

ORB

Java

ORB

IIOP

Java client A

client stub

shared object

server skeleton

Java client A

client stub

IR

IR


Java developments
Java Developments long-lived objects

  • Personal Java

  • Embedded Java

  • Java Card

  • JavaOS


Personal java
Personal Java long-lived objects

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

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

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


Personal java api
Personal Java API long-lived objects

  • Features can be optionally supported

    • Example: printing, math functions

    • Throws exception if unsupported

  • Redefines java.awt (smaller)

    • Graphics and windowing support

    • Supports low-resolution displays

    • Supports alternate input devices


Personal java machine requirements
Personal Java Machine Requirements long-lived objects

  • Processor: 32 bit , 50+ MHz

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

  • Network connection

  • Keyboard or alternate input

  • Requirements do not include space for application code and data

  • Runs on major real-time OS’s


Embedded java
Embedded Java long-lived objects

  • 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


Embedded java components
Embedded Java Components long-lived objects

Application

Classes

Embedded Java

Classes

Hardware

Classes

Static

Data

filter and compact code

compact data

staticData.c

ROMjava.c

Developer

Embedded Java

Vendor

Native compiler

ROMjava.o

staticData.o

Virtual

Machine

native

methods

native

linker

OS image

ROMlet


Personal vs embedded java
Personal vs. Embedded Java long-lived objects

  • Share many of the same development tools

  • Both upward compatible with standard Java

  • Personal Java - Support multiple Java apps with certain features

  • Embedded - Tune system for one Java application


Personal java key points
Personal Java Key Points long-lived objects

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

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


Embedded java key points
Embedded Java Key Points long-lived objects

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

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


Javacard goals
JavaCard Goals long-lived objects

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

  • Device requirements

    • 16K of ROM

    • 8K of EEPROM (non-volatile)

    • 256 bytes of RAM


Javacard solution
JavaCard Solution long-lived objects

  • Provide a scaled down VM implementation

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

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


Javacard vm
JavaCard VM long-lived objects

  • Minimal VM, no support for:

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

    • Dynamic class loading

    • Security manager

    • Threads and synchronization

    • Object cloning

    • Finalization (Specification does not require Garbage Collection)


Javacard split vm
JavaCard Split VM long-lived objects

  • Off-card

    • Class loading, linking, resolution

    • Verification

    • Bytecode optimization and conversions

  • On-card

    • Bytecode execution


Java card applets
Java Card Applets long-lived objects

  • Additional framework for card applets

    • Communications protocol w/ terminal

    • File system compatible w/ industry standard

    • Cryptographic functions


Java card applets1
Java Card Applets long-lived objects

  • Installation:

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

    • Other JavaCard applets can be installed after card is issued


Java card considerations
Java Card Considerations long-lived objects

  • Assume external power source

    • Machine state must remain consistent with loss of power

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

    • General objects stored in EEPROM

    • Objects declared transient can reside in RAM


Java card considerations1
Java Card Considerations long-lived objects

  • Memory space is limited

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


Javaos features
JavaOS Features long-lived objects

  • Machines that only run Java programs can bypass host OS

    • Allows precise tuning for Java performance

    • Minimal memory requirements

  • Intended to scale across wide range of hardware platforms

  • Portable drivers (written in Java)


Javaos architecture
JavaOS Architecture long-lived objects

  • Native-Java abstraction at lowest possible level

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

    • Interrupt Classes

    • Java Platform Interface (JPI) to machine dependent microkernel


Javaos architecture layers
JavaOS Architecture Layers long-lived objects

  • Microkernel and Memory Manager (native)

  • Device Drivers (mostly bytecode)

  • Java Virtual Machine (bytecode, calls native system functions)

  • JavaOS Graphics and Windowing systems (bytecode)

  • Full Java API (bytecode)


Javaos components
JavaOS Components long-lived objects

Core Java Classes

Java Language Classes

AWT

Classes

I/O

Classes

JavaOS Runtime

AWT

Support

I/O

Support

Java Virtual Machine

JavaOS

Device Drivers

JavaOS Platform Interface

JavaOS Microkernel


Disclaimer
Disclaimer long-lived objects

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.


Java programming
Java Programming long-lived objects

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

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


Java virtual machine
Java Virtual Machine long-lived objects

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

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

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


Distributed objects
Distributed Objects long-lived objects

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

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

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


COM long-lived objects

  • Don Box. Essential COM. Addison-Wesley, 1998.

  • Dale Rogerson, Inside COM, Microsoft Press, 1997.

  • "The Component Object Model Specification." Microsoft Corp., draft version 0.9 edition, 1995.

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


Static java to native compilers
Static, Java to native compilers: long-lived objects

  • Supercede, Inc., Supercede, www.supercede.com

  • Tower Technology Corporation, TowerJ, www.twr.com

  • Symantec Corporation, VisualCafe, www.symantec.com/domain/cafe/

  • Open Group Research Institute, TurboJ, www.camb.opengroup.org /openitsol/turboj/


Other products
Other Products long-lived objects

  • Sybase, Inc., Adaptive Server and Java, Whitepaper, www.sybase.com/adaptiveserver /whitepapers/java_wps.html

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


Java specifications sun microsystems inc
Java Specifications long-lived objectsSun 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/


ad