C and java
Advertisement
This presentation is the property of its rightful owner.
1 / 84

C++ and Java PowerPoint PPT Presentation

C++ and Java. Chris Stork most slides stolen from John Mitchell (chapter 12 & 13). C++ History. C++ is an object-oriented extension of C C was designed by Dennis Ritchie at Bell Labs used to write Unix based on BCPL C++ designed by Bjarne Stroustrup at Bell Labs

Download Presentation

C++ and Java

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


C and java

C++ and Java

Chris Stork

most slides stolen from John Mitchell (chapter 12 & 13)


C history

C++ History

  • C++ is an object-oriented extension of C

  • C was designed by Dennis Ritchie at Bell Labs

    • used to write Unix

    • based on BCPL

  • C++ designed by Bjarne Stroustrup at Bell Labs

    • His original interest at Bell was research on simulation

    • Early extensions to C are based primarily on Simula

    • Called “C with classes” in early 1980’s

    • Popularity increased in late 1980’s and early 1990’s

    • Features were added incrementally

      Classes, templates, exceptions, multiple inheritance, type tests...


C design goals

C++ Design Goals

  • Provide object-oriented features in C-based language, without compromising efficiency

    • Backwards compatibility with C

    • Better static type checking

    • Data abstraction

    • Objects and classes

    • Prefer efficiency of compiled code where possible

  • Important principle

    • If you do not use a feature, your compiled code should be as efficient as if the language did not include the feature. (compare to Smalltalk)


How successful

How successful?

  • Given the design goals and constraints,

    • this is a very well-designed language

  • Many users -- tremendous popular success

  • However, very complicated design

    • Many specific properties with complex behavior

    • Difficult to predict from basic principles

    • Most serious users chose subset of language

      • Full language is complex and unpredictable

    • Many implementation-dependent properties

    • Language for adventure game fans


Further evidence

Further evidence

  • Many style guides for using C++ “safely”

  • Many conventions and prohibitions to reduce complexity

    • CORBA -- don’t inherit implementation

    • SGI compiler group -- no virtual functions

    • Others -- ???

      See Cargill’sC++ Programming Stylebook or even Stroustrup's The C++ Programming Language, 3rd ed. (also check out http://www.research.att.com/~bs/C++.html)


Significant constraints

Significant constraints

  • C has specific machine model

    • Access to underlying architecture

  • No garbage collection

    • Consistent with goal of efficiency

    • Need to manage object memory explicitly

  • Local variables stored in activation records

    • Objects treated as generalization of structs, so some objects may be allocated on stack

    • Stack/heap difference is visible to programmer


Overview of c

Overview of C++

  • Additions and changes not related to objects

    • type bool

    • pass-by-reference

    • user-defined overloading

    • function templates

    • exceptions


C object system

C++ Object System

  • Object-oriented features

    • Classes

    • Objects, with dynamic lookup of virtual functions

    • Inheritance

      • Single and multiple inheritance

      • Public and private base classes

    • Subtyping

      • Tied to inheritance mechanism

    • Encapsulation


Some good decisions

Some good decisions

  • Public, private, protected levels of visibility

    • Public: visible everywhere

    • Protected: within class and subclass declarations

    • Private: visible only in class where declared

  • Friend functions and classes

    • Careful attention to visibility and data abstraction

  • Allow inheritance without subtyping

    • Better control of subtyping than without private base classes


Some problem areas

Some problem areas

  • Casts

    • Sometimes no-op, sometimes not (esp multiple inher)

  • Lack of garbage collection

    • Memory management is error prone

      • Constructors, destructors are helpful though

  • Objects allocated on stack

    • Better efficiency, interaction with exceptions

    • BUT assignment works badly, possible dangling ptrs

  • Overloading

    • Too many code selection mechanisms

  • Multiple inheritance

    • Efforts at efficiency lead to complicated behavior


Sample class one dimenional points

Sample class:one-dimenional points

class Pt {

public:

Pt(int xv);

Pt(Pt* pv);

int getX();

virtual void move(int dx);

protected:

void setX(int xv);

private:

int x;

};

Overloaded constructor

Public read access to private data

Virtual function

Protected write access

Private member data


Virtual functions

Virtual functions

  • Member functions are either

    • Virtual, if explicitly declared or inherited as virtual

    • Non-virtual otherwise

  • Virtual members

    • Are accessed by indirection through ptr in object

    • May be redefined in derived (sub) classes

  • Non-virtual functions

    • Are called in the usual way. Just ordinary functions.

    • Not redefinable in derived classes (except overloading)

  • Pay overhead only if you use virtual functions


Sample derived class

Sample derived class

Public base class gives supertype

class ColorPt: public Pt {

public:

ColorPt(int xv,int cv);

ColorPt(Pt* pv,int cv);

ColorPt(ColorPt* cp);

int getColor();

virtual void move(int dx);

virtual void darken(int tint);

protected:

void setColor(int cv);

private:

int color;

};

Overloaded constructor

Non-virtual function

Virtual functions

Protected write access

Private member data


Run time representation

Run-time representation

Point object

Point vtable

Code for move

vptr

3

x

ColorPoint object

ColorPoint vtable

Code for move

vptr

x

5

Code for darken

c

blue

Data at same offset

Function pointers at same offset


Compare to smalltalk

Compare to Smalltalk

Point class

Template

Point object

Method dictionary

x

newX:Y:

y

2

...

...

3

move

ColorPoint class

Template

ColorPoint object

Method dictionary

x

newX:Y:C:

y

4

color

color

5

move

red


Why is c lookup simpler

Why is C++ lookup simpler?

  • Smalltalk has no static type system

    • Code p message:pars could refer to any object

    • Need to find method using pointer from object

    • Different classes will put methods at different place in method dictionary

  • C++ type gives compiler some superclass

    • Offset of data, fctn ptr same in subclass and superclass

    • Offset of data and function ptr known at compile time

    • Code p->move(x) compiles to equivalent of

      (*(p->vptr[1]))(p,x) if move is first fctn in vtable.

data passed to member function; see next slide


Calls to virtual functions

Calls to virtual functions

  • One member function may call another

    class A {

    public:

    virtual int f (int x);

    virtual int g(int y);

    };

    int A::f(int x) { … g(i) …;}

    int A::g(int y) { … f(j) …;}

  • How does body of f call the right g?

    • If g is redefined in derived class B, then inherited f must call B::g


This pointer analogous to self in smalltalk

“This” pointer (analogous to self in Smalltalk)

  • Code is compiled so that member function takes “object itself” as first argument

    Code int A::f(int x) { … g(i) …;}

    compiled asint A::f(A *this, int x) { … this->g(i) …;}

  • “this” pointer may be used in member function

    • Can be used to return pointer to object itself, pass pointer to object itself to another function, ...


Non virtual functions

Non-virtual functions

  • How is code for non-virtual function found?

  • Same way as ordinary “non-member” functions:

    • Compiler generates function code and assigns address

    • Address of code is placed in symbol table

    • At call site, address is taken from symbol table and placed in compiled code

    • Butsome special scoping rules for classes

  • Overloading

    • Remember: overloading is resolved at compile time

    • This is different from run-time lookup of virtual function


Scope rules in c

Scope rules in C++

  • Scope qualifiers

    • binary :: operator, ->, and .

    • class::member, ptr->member, object.member

  • A name outside a function or class,

    • not prefixed by unary :: and not qualified refers to global object, function, enumerator or type.

  • A name after X::, ptr-> or obj.

    • where we assume ptr is pointer to class X and obj is an object of class X

    • refers to a member of class X or a base class of X


Virtual vs overloaded functions

Virtual vs Overloaded Functions

class parent { public:

void printclass() {printf("p ");};

virtual void printvirtual() {printf("p ");}; };

class child : public parent { public:

void printclass() {printf("c ");};

virtual void printvirtual() {printf("c ");}; };

main() {

parent p; child c; parent *q;

p.printclass(); p.printvirtual(); c.printclass(); c.printvirtual();

q = &p; q->printclass(); q->printvirtual();

q = &c; q->printclass(); q->printvirtual();

}

Output: p p c c p p p c


Subtyping

Subtyping

  • Subtyping in principle

    • A <: B if every A object can be used without type error whenever a B object is required

    • Example:

      Point: int getX();

      void move(int);

      ColorPoint: int getX();

      int getColor();

      void move(int);

      void darken(int tint);

  • C++: A <: B if class A has public base class B

    • This is weaker than necessary. Why?

Public members

Public members


Independent classes not subtypes

Independent classes not subtypes

class Point {

public:

int getX();

void move(int);

protected: ...

private: ...

};

class ColorPoint {

public:

int getX();

void move(int);

int getColor();

void darken(int);

protected: ...

private: ...

};

  • C++ does not treat ColorPoint <: Point as written

    • Need public inheritance ColorPoint : public Pt

    • Why??


Why subtyping by declaration

Why Subtyping by declaration?

  • Client code depends only on declared public superclass

    • In principle, if ColorPoint interface contains Point interface, then any client could use ColorPoint in place of point

    • However -- offset in virtual function table may differ

    • Lose implementation efficiency (like Smalltalk)

  • Without link to inheritance…

    • subtyping leads to loss of implementation efficiency

  • Also encapsulation & maintenance issue:

    • Subtyping based on inheritance is preserved under modifications to base class …


Details details

Details, details

  • This is legal

    class Point { …

    virtual Point * move(int);

    … }

    class ColorPoint: public Point { …

    virtual ColorPoint * move(int);

    … }

  • But not legal if *’s are removed

    class Point { … virtual Point move(int); … }

    class ColorPoint: public Point { …virtual ColorPoint move(int);… }

    Related to subtyping distinctions for object L-values and object R-values

    (Non-pointer return type is treated like an L-value for some reason)


Subtyping and object l r values

Subtyping and Object L,R-Values

  • If class B : public A { … }

    Then

    • B r-value <: A r-value

      • If x = a is OK, then x = b is OK

        provided A’s operator = is public

      • If f(a) is OK, then f(b) is OK

        provided A’s copy constructor is public

    • B l-value <: A l-value

    • B* <: A*

    • B** <: A**

      Generally, X <: Y  X* <: Y* is unsound.


Review

Review

  • Why C++ requires inheritance for subtyping

    • Need virtual function table to look the same

    • This includes private and protected members

    • Subtyping w/o inheritance weakens data abstraction

      (This is my post facto explanation; I don’t know what designers think.)

  • Possible confusion regarding inlining

    • Cannot generally inline virtual functions

    • Inlining is possible for nonvirtual functions

      • These are available in C++

      • Not in Smalltalk since every lookup is through class

        Inlining is very significant for efficiency; enables further optimization.


Abstract classes

Abstract Classes

  • Abstract class:

    • A class without complete implementation

    • Declare by =0

    • Useful because it can have derived classes

      Since subtyping follows inheritance in C++, use abstract classes to build subtype hierarchies.

    • Establishes layout of virtual function table (vtable)

  • Example

    • Geometry classes in appendix of Mitchell book (A.1.2)

      • Shape is abstract supertype of circle, rectangle, ...


Multiple inheritance

Shape

ReferenceCounted

Rectangle

RefCounted

Rectangle

Multiple Inheritance

Inherit independent functionality from independent classes


Problem name clashes

Problem: Name Clashes

class A {

public:

void virtual f() { … }

};

class B {

public:

void virtual f() { … }

};

class C : public A, public B { … };

C* p;

p->f(); // error

same name in 2 base classes


Possible solutions to name clash

Possible solutions to name clash

  • Three general approaches

    • Implicit resolution

      • Language resolves name conflicts with arbitrary rule

    • Explicit resolution

      • Programmer must explicitly resolve name conflicts

    • Disallow name clashes

      • Programs are not allowed to contain name clashes

  • No solution is always best

  • C++ uses explicit resolution


Repair to previous example

Repair to previous example

  • Rewrite class C to call A::f explicitly

    class C : public A, public B {

    public:

    void virtual f( ) {

    A::f( ); // Call A::f(), not B::f();

    }

  • Reasonable solution

    • This eliminates ambiguity

    • Preserves dependence on A

      • Changes to A::f will change C::f


Vtable for multiple inheritance

vtable for Multiple Inheritance

class A {

public:

int x;

virtual void f();

};

class B {

public:

int y;

virtual void g();

virtual void f();

};

class C: public A, public B {

public:

int z;

virtual void f();

};

C *pc = new C;

B *pb = pc;

A *pa = pc;

Three pointers to same object, but different static types.


Object and classes

A

B

Object and classes

C

  • Offset  in vtbl is used in call to pb->f, since C::f may refer to A data that is above the pointer pb

  • Call to pc->g can proceed through C-as-B vtbl

C object

C-as-A vtbl

& C::f

0

pa, pc

vptr

A object

A data

C-as-B vtbl

pb

vptr

& B::g

0

B object

B data

& C::f

C data


Multiple inheritance diamond

Window (D)

Text Window (A)

Graphics Window (B)

Text, Graphics

Window (C)

Multiple Inheritance “Diamond”

  • Is interface or implementation inherited twice?

  • What if definitions conflict?


Diamond inheritance in c

D

A

B

C

Diamond inheritance in C++

  • Standard base classes

    • D members appear twice in C

  • Virtual base classes

    class A : public virtual D { … }

    • Avoid duplication of base class members

    • Require additional pointers so that D part of A, B parts of object can be shared

A part

B part

C part

D part

  • C++ multiple inheritance is complicated in part because of desire to maintain efficient lookup


C summary

C++ Summary

  • Objects

    • Created by classes

    • Contain member data and pointer to class

  • Classes: virtual function table

  • Inheritance

    • Public and private base classes, multiple inheritance

  • Subtyping: Occurs with public base classes only

  • Encapsulation

    • member can be declared public, private, protected

    • object initialization partly enforced


Lecture15

Language Overview

History and design goals

Classes and Inheritance

Object features

Encapsulation

Inheritance

Types and Subtyping

Primitive and ref types

Interfaces; arrays

Subtype polymorphism and generic programming

Java virtual machine

Loader and initialization

Linker and verifier

Bytecode interpreter

Security

Buffer overflow

Java “sandbox”

Type safety and attacks

Java


History

History

  • James Gosling and others at Sun, 1990 - 95

  • Oak language for “set-top box”

    • small networked device with television display

      • graphics

      • execution of simple programs

      • communication between local program and remote site

      • no “expert programmer” to deal with crash, etc.

  • Internet application

    • simple language for writing programs that can be transmitted over network


Gates saw java as real threat

Gates Saw Java as Real Threat

Publicly, Microsoft chief Bill Gates was nearly dismissive when he talked in 1996 about Sun Microsystems' Java programming language. But in internal company discussions, he wrote to staff members that Java and the threat the cross-platform technology posed to his company's Windows operating systems "scares the hell out of me."

Wired News Report8:09 a.m. 22.Oct.98.PDT (material from ‘98 trial)


Design goals

Design Goals

  • Portability

    • Internet-wide distribution: PC, Unix, Mac

  • Reliability

    • Avoid program crashes and error messages

  • Safety

    • Programmer may be malicious

  • Simplicity and familiarity

    • Appeal to average programmer; less complex than C++

  • Efficiency

    • Important but secondary


General design decisions

General design decisions

  • Simplicity

    • Almost everything is an object

    • All objects on heap, accessed through pointers

    • No functions, no multiple inheritance, no go to, no operator overloading, no automatic coercions

  • Portability and network transfer

    • Bytecode interpreter on many platforms

  • Reliability and Safety

    • Typed source and bytecode language

    • Run-time type and bounds checks

    • Garbage collection


Java system

Java System

  • The Java programming language

  • Compiler and run-time system

    • Programmer compiles code

    • Compiled code transmitted on network

    • Receiver executes on interpreter (JVM)

    • Safety checks made before/during execution

  • Library, including graphics, security, etc.

    • Large library made it easier for projects to adopt Java

    • Interoperability

      • Provision for “native” methods


Language terminology

Language Terminology

  • Class, object - as in other languages

  • Field – data member

  • Method - member function

  • Static members - class fields and methods

  • this - self

  • Package - set of classes in shared namespace

  • Native method - method written in another language, typically C


Java classes and objects

Java Classes and Objects

  • Syntax similar to C++

  • Object

    • has fields and methods

    • is allocated on heap, not run-time stack

    • accessible through reference (only ptr assignment)

    • garbage collected

  • Dynamic lookup

    • Similar in behavior to other languages

    • Static typing => more efficient than Smalltalk

    • Dynamic linking, interfaces => slower than C++


Point class

Point Class

class Point {

private int x;

protected void setX (int y) {x = y;}

public int getX() {return x;}

Point(int xval) {x = xval;} // constructor

};

  • Visibility similar to C++, but not exactly


Object initialization

Object initialization

  • Java guarantees constructor call for each object

    • Memory allocated

    • Constructor called to initialize memory

    • Some interesting issues related to inheritance

      • We’ll discuss later …

  • Cannot do this (would be bad C++ style):

    • Obj* obj = (Obj*)malloc(sizeof(Obj));

      use new instead …

  • Static fields of class initialized at class load time

    • Talk about class loading later


Garbage collection and finalize

Garbage Collection and Finalize

  • Objects are garbage collected

    • No explicit free

    • Avoid dangling pointers, resulting type errors

  • Problem

    • What if object has opened file or holds lock?

  • Solution

    • finalize method, called by the garbage collector

      • Before space is reclaimed, or when virtual machine exits

      • Space overflow is not really the right condition to trigger finalization when an object holds a lock...)

    • Important convention: call super.finalize


Encapsulation and packages

package

package

class

class

field

field

method

method

Encapsulation and packages

  • Every field, method belongs to a class

  • Every class is part of some package

    • Can be unnamed default package

    • File declares which package code belongs to


Visibility and access

Visibility and access

  • Four visibility distinctions

    • public, private, protected, package

  • Method can refer to

    • private members of class it belongs to

    • non-private members of all classes in same package

    • protected members of superclasses (in diff package)

    • public members of classes in visible packages

      Visibility determined by files system, etc. (outside language)

  • Qualified names (or use import)

    • java.lang.String.substring()

package

class

method


Inheritance

Inheritance

  • Similar to Smalltalk, C++

  • Subclass inherits from superclass

    • Single inheritance only (but see interfaces)

  • Some additional features

    • Conventions regarding super in constructor and finalize methods

    • Final classes and methods


Example subclass

Example subclass

class ColorPoint extends Point {

// Additional fields and methods

private Color c;

protected void setC (Color d) {c = d;}

public Color getC() {return c;}

// Define constructor

ColorPoint(int xval, Color cval) {

super(xval); // call Point constructor

c = cval;} // initialize ColorPoint field

};


Final classes and methods

Final classes and methods

  • Restrict inheritance

    • Final classes and methods cannot be redefined

  • Example

    java.lang.String

  • Reasons for this feature

    • Important for security

      • Programmer controls behavior of all subclasses

      • Critical because subclasses produce subtypes

    • Compare to C++ virtual/non-virtual

      • Method is “virtual” until it becomes final


Class object

Class Object

  • Every class extends another class

    • Superclass is Object if no other class named

  • Methods of class Object

    • GetClass – return the Class object representing class of the object

    • ToString – returns string representation of object

    • equals – default object equality (not ptr equality)

    • hashCode

    • Clone – makes a duplicate of an object

    • wait, notify, notifyAll – used with concurrency

    • finalize


Java types and subtyping

Java Types and Subtyping

  • Primitive types – not objects

    • Integers, Booleans, etc

  • Reference types

    • Classes, interfaces, arrays

    • No syntax distinguishing Object * from Object

  • Type conversion

    • If A <: B, and B x, then can cast x to A

    • Casts checked at run-time, may raise exception


Class and interface subtyping

Class and Interface Subtyping

  • Class subtyping similar to C++

    • Statically typed language

    • Subclass produces subtype

    • Single inheritance => subclasses form tree

  • Interfaces

    • Completely abstract classes

      • no implementation

      • Java also has abstract classes (without full impl)

    • "Multiple subtyping"

      • A class may implement multiple interfaces


Example

Example

interface Shape {

public float center();

public void rotate(float degrees);

}

interface Drawable {

public void setColor(Color c);

public void draw();

}

class Circle implements Shape, Drawable {

// does not inherit any implementation

// but must define Shape, Drawable methods

}


Properties of interfaces

Properties of interfaces

  • Flexibility

    • Allows subtype graph instead of tree

    • Avoids problems with multiple inheritance of implementations (remember C++ “diamond”)

  • Cost

    • Offset in method lookup table not known at compile-time

    • Different bytecodes for method lookup

      • one when class is known

      • one when only interface is known

        • search for location of method

        • cache for use next time this call is made (from this line)


Java class subtyping

Java class subtyping

  • Signature Conformance

    • Subclass method signatures must conform to those of superclass

  • Three ways signature could vary

    • Argument types

    • Return type

    • Exceptions (different from C#)

      How much conformance is needed in principle?

  • Java rule

    • Arguments and returns must have identical types, may remove exceptions


Classification of java types

Classification of Java types

Reference Types

Object

Object[ ]

Throwable

Shape

Shape[ ]

Exception types

Circle

Square

Circle[ ]

Square[ ]

user-defined

arrays

Primitive Types

boolean

int

byte

float

long


Array types

Array types

  • Automatically defined

    • Array type T[ ] exists for each class, interface type T

    • Cannot extended array types (array types are final)

    • Multi-dimensional arrays as arrays of arrays: T[ ] [ ]

  • Reference type

    • An array variable is a pointer to an array, can be null

    • Example: Circle[] x = new Circle[array_size]

    • Anonymous array expression: new int[] {1,2,3, ... 10}

  • Every array type is a subtype of Object[ ], Object

    • Length of array is not part of its static type


Array subtyping

Array subtyping

  • Covariance

    • if S <: T then S[ ] <: T[ ]

  • Standard type error

    class A {…}

    class B extends A {…}

    B[ ] bArray = new B[10]

    A[ ] aArray = bArray // considered OK since B[] <: A[]

    aArray[0] = new A() // allowed but run-time type error

    // raises ArrayStoreException


Afterthought on java arrays

Afterthought on Java arrays

Date: Fri, 09 Oct 1998 09:41:05 -0600

From: bill joy

Subject: …[discussion about java genericity]

actually, java array covariance was done for less noble reasons …: it made some generic "bcopy" (memory copy) and like operations much easier to write...

I proposed to take this out in 95, but it was too late (...).

i think it is unfortunate that it wasn't taken out...

it would have made adding genericity later much cleaner, and [array covariance] doesn't pay for its complexity today.

wnj


But compare this to c

But compare this to C++!!

  • Access by pointer: you can't do array subtyping.

    B* barr[15];

    A* aarr[] = barr; // not allowed

  • Direct naming: allowed, but you get garbage !!

    B barr[15];

    A aarr[] = barr;

    aarr[k] translates to *(aarr+sizeof(A)*k)

    barr[k] translates to *(barr+sizeof(B)*k)

    If sizeof(B) != sizeof(A), you just grab random bits.

    Is there any sense to this?


Why no templates in java 1 1

Why no templates in Java 1.1?

  • Many proposals

  • Basic language goals seem clear

  • Details take some effort to work out

    • Exact typing constraints

    • Implementation

      • Existing virtual machine?

      • Additional bytecodes?

      • Duplicate code for each instance?

      • Use same code (with casts) for all instances

Java Community proposal (JSR 14) planned for release in Java 1.5


Jsr 14 java generics java 1 5 tiger

JSR 14 Java Generics (Java 1.5, “Tiger”)

  • Without generics

    class Dictionary {

    Object put(Object key, Object value) {...}

    Object get(Object key) {...}

    ... }

  • With generics

    class Dictionary <Key, Value> {

    Value put(Key k, Value v) {...}

    Value get(Key k) {...}

    ... }

    Dictionary <Integer, String> h

    = new Dictionary <Integer, String>();

    h.put(new Integer(0), "value");

    String s = h.get(k);


Java implementation

Java Implementation

  • Compiler and Virtual Machine

    • Compiler produces bytecode

    • Virtual machine loads classes on demand, verifies bytecode properties, interprets bytecode

  • Why this design?

    • Bytecode interpreter/compilers used before

      • Pascal “pcode”; Smalltalk compilers use bytecode

    • Minimize machine-dependent part of implementation

      • Do optimization on bytecode when possible

      • Keep bytecode interpreter simple

    • For Java, this gives portability

      • Transmit bytecode across network


Lecture15

Java Virtual Machine Architecture

A.java

A.class

Java

Compiler

Compile source code

Java Virtual Machine

Loader

Network

B.class

Verifier

Linker

Bytecode Interpreter


Jvm class loader linker and verifier

JVM Class loader, Linker, and Verifier

  • Class loader

    • When class is referenced, loader searches for file of compiled bytecode instructions

  • Verifier

    • Check bytecode for class or interface before linked

    • Throw VerifyError exception if error occurs

  • Linker

    • Adds compiled class or interface to runtime system

    • Creates static fields and initializes them

    • Resolves names

      • Checks symbolic names and replaces with direct references


Static members and initialization

Static members and initialization

class ... {

/* static variable with initial value */

static int x = initial_value

/* ---- static initialization block --- */

static { /* code executed once, when loaded */ }

}

  • Initialization is important

    • Cannot initialize class fields until loaded

  • Static block cannot raise an exception

    • Handler may not be installed at class loading time


Verifier

Verifier

  • Bytecode may not come from standard compiler

    • Evil hacker may write dangerous bytecode

  • Verifier checks correctness of bytecode

    • Every instruction must have a valid operation code

    • Every branch instruction must branch to the start of some other instruction, not middle of instruction

    • Every method must have a structurally correct signature

    • Every instruction obeys the Java type discipline

      Last condition is fairly complicated .


Bytecode interpreter

Bytecode interpreter

  • Standard virtual machine interprets instructions

    • Perform run-time checks such as array bounds

    • Possible to compile bytecode class file to native code

  • Java programs can call native methods

    • Typically functions written in C

  • Multiple bytecodes for method lookup

    • invokevirtual - when class of object known

    • invokeinterface - when interface of object known

    • invokestatic - static methods

    • invokespecial - some special cases


Jvm memory areas

JVM memory areas

  • Java program has one or more threads

  • Each thread has its own stack

  • All threads share same heap

method area

heap

Java stacks

PC registers

native method stacks


Jvm uses stack machine

JVM uses stack machine

  • Java

    Class A extends Object {

    int i

    void f(int val) { i = val + 1;}

    }

  • Bytecode

    Method void f(int)

    aload 0 ; object ref this

    iload 1 ; int val

    iconst 1

    iadd ; add val +1

    putfield #4 <Field int i>

    return

JVM Activation Record

local variables

operandstack

Return addr, exception info, Const pool res.

data area

  • refers to const pool


Type safety of jvm

Type Safety of JVM

  • Run-time type checking

    • All casts are checked to make sure type safe

    • All array references are checked to make sure the array index is within the array bounds

    • References are tested to make sure they are not null before they are dereferenced.

  • Additional features

    • Automatic garbage collection

    • NO pointer arithmetic

      If program accesses memory, the memory is allocated to the program and declared with correct type


Java security

Java Security

  • Security

    • Prevent unauthorized use of computational resources

  • Java security

    • Java code can read input from careless user or malicious attacker

    • Java code can be transmitted over network –

      code may be written by careless friend or malicious attacker

      Java is designed to reduce many security risks


Buffer overflow attack

Buffer Overflow Attack

  • Most prevalent security problem today

    • Approximately 80% of CERT advisories are related to buffer overflow vulnerabilities in OS, other code

  • General network-based attack

    • Attacker sends carefully designed network msgs

    • Input causes privileged program (e.g., Sendmail) to do something it was not designed to do

  • Does not work in Java

    • Illustrates what Java was designed to prevent


Sample c code to illustrate attack

void f (char *str) {

char buffer[16];

strcpy(buffer,str);

}

void main() {

char large_string[256];

int i;

for( i = 0; i < 255; i++)

large_string[i] = 'A';

f(large_string);

}

Function

Copies str into buffer until null character found

Could write past end of buffer, over function retun addr

Calling program

Writes 'A' over f activation record

Function f “returns” to location 0x4141414141

This causes segmentation fault

Variations

Put meaningful address in string

Put code in string and jump to it !!

Sample C code to illustrate attack

See: Smashing the stack for fun and profit


Java sandbox

Java Sandbox

  • Four complementary mechanisms

    • Class loader

      • Separate namespaces for separate class loaders

      • Associates protection domain with each class

    • Verifier and JVM run-time tests

      • NO unchecked casts or other type errors, NO array overflow

      • Preserves private, protected visibility levels

    • Security Manager

      • Called by library functions to decide if request is allowed

      • Uses protection domain associated with code, user policy

      • Recall: stack inspection problem on midterm


Why is typing a security feature

Why is typing a security feature?

  • Sandbox mechanisms all rely on type safety

  • Example

    • Unchecked C cast lets code make any system call

      int (*fp)() /* variable "fp" is a function pointer */

      ...

      fp = addr; /* assign address stored in an integer var */

      (*fp)(n); /* call the function at this address */

      Other examples using Java type confusion in book


Java summary

Java Summary

  • Objects

    • have fields and methods

    • alloc on heap, access by pointer, garbage collected

  • Classes

    • Public, Private, Protected, Package (not exactly C++)

    • Can have static (class) members

    • Constructors and finalize methods

  • Inheritance

    • Single inheritance

    • Final classes and methods


Java summary ii

Java Summary (II)

  • Subtyping

    • Determined from inheritance hierarchy

    • Class may implement multiple interfaces

  • Virtual machine

    • Load bytecode for classes at run time

    • Verifier checks bytecode

    • Interpreter also makes run-time checks

      • type casts

      • array bounds

    • Portability and security are main considerations


Comparison with c

Comparison with C++

  • Almost everything is object + Simplicity - Efficiency

    • except for values from primitive types

  • Type safe + Safety +/- Code complexity - Efficiency

    • Arrays are bounds checked

    • No pointer arithmetic, no unchecked type casts

    • Garbage collected

  • Interpreted + Portability + Safety - Efficiency

    • Compiled to byte code: a generalized form of assembly language designed to interpret quickly.

    • Byte codes contain type information


Comparison cont d

Comparison (cont’d)

  • Objects accessed by ptr + Simplicity - Efficiency

    • No problems with direct manipulation of objects

  • Garbage collection: + Safety + Simplicity - Efficiency

    • Needed to support type safety

  • Built-in concurrency support + Portability

    • Used for concurrent garbage collection

    • Concurrency control via synchronous methods

    • Part of network support: download data while executing

  • Exceptions

    • As in C++, integral part of language design


  • Login