Objects and Classes David Walker CS 320

Advanced Languages advanced programming features –ML data types, exceptions, modules, objects, concurrency,... –fun to use, but require special techniques to compile and optimize –today will be looking at how to compile objects and classes similar to those found in Java Appel chapter

Object Fun Add class declarations to Fun: –classes are a collection of field (variable) declarations method declarations –every class declaration gives a new name to a class –a class may inherit methods and fields from the class it extends –the class object sits at the top of the class hierarchy; it has no fields and no methods

An Object Fun Class let class Vehicle extends Object { var position := start method move (x : int) = (position := position + x) } in... end class name superclass that Vehicle inherits from field declaration method declaration

Another Object Fun Class let class Vehicle extends Object { var position := start method move (x:int) = (position := position + x) } class Car extends Vehicle { var passengers := 0 method await(v:Vehicle) = if (v.position < position) then v.move(position – v.position) else self.move(10) in... end vs position field current objects position field call to inherited method new field declaration new method declaration

Yet Another Object Fun Class let class Vehicle extends Object { var position := start method move (x:int) = position := position + x } class Car extends Vehicle {... } class Truck extends Vehicle { method move (x:int) = if x <= 55 then position := position * x } in... end method override

Using the Classes let class Vehicle extends Object {... } class Car extends Vehicle {... } class Truck extends Vehicle {...} val t = new Truck val c = new Car val v : Vehicle = c in c.passengers := 2; c.move(60); v.move(70); c.await(t); end new object created subtyping allows a car to be viewed and used as a generic vehicle subtyping allows a truck to be viewed and used as a generic vehicle a car calls an inherited method

Implementing Object Tiger Some key problems: –how do we access object fields? both inherited fields and fields for the current object? –how do we access method code? if the current class does not define a particular method, where do we go to get the inherited method code? how do we handle method override?

Class Hierarchy The class hierarchy is the graph of inheritence relationships in a program: –In a single-inheritence (SI) language, the graph is a tree –In a multiple-inheritence (MI) language, the graph is a dag –Multiple-inheritence languages are much trickier to implement than single-inheritence languages Object Vehicle CarTruck

Object Layout (SI) Objects are laid out somewhat like records –each variable has a slot in the record –in order to implement field lookup we need to have a systematic way to find a given field eg: v.position the hard part is that v may be a generic Vehicle or it may be a Car or a Truck the same lookup code must work when we know the static type (say Vehicle) but we do not know the dynamic type of the object (say Vehicle, Car or Truck) we need to put position in the same place in the record that implements vehicles, cars and trucks

Using the Classes let class Vehicle extends Object {... } class Car extends Vehicle { var passengers := 0 method await(v:Vehicle) = if (v.position < position) then... } class Truck extends Vehicle {...} val t = new Truck val c = new Car val v : Vehicle = c in c.await(t); c.await(c); c.await(v) end assume v is a pointer in rv v.position (for SI) gets compiled into: load rtemp const(rv) what const do we use? must be the same constant regardless of whether v is a car, truck or vehicle the layout of fields in records that implement cars, trucks and vehicles must be similar.

Object Layout (SI) Solution: extension on the right –lay out the inherited fields first in the same order as in the parent (SI => only 1 parent) –lay out the newly declared to the right

Object Layout (SI) class A extends Object { var a := 0 } class B extends A { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends B { var e := 0 }

Object Layout (SI) class A extends Object { var a := 0 } class B extends A { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends B { var e := 0 } A a class identifier; used to implement downcasts; first field in all classes must be the class identifier first field named a; all objects extending A must have first field a

Object Layout (SI) class A extends Object { var a := 0 } class B extends A { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends B { var e := 0 } B a b c A a

Object Layout (SI) class A extends Object { var a := 0 } class B extends A { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends B { var e := 0 } C a d B a b c A a

Object Layout (SI) class A extends Object { var a := 0 } class B extends A { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends B { var e := 0 } D a b c e C a d B a b c A a

Static & Dynamic Methods The result of compiling a method is some machine code located at a particular address –at a method invocation point, we need to figure out what code location to jump to Java has static & dynamic methods –to resolve static method calls, we look at the static type of the calling object –to resolve dynamic method calls, we need the dynamic type of the calling object

Static Methods –during semantic analysis, the compiler knows: static type (class) of the object calling the method the list of methods in each class –and determines the closest method (up the class hierarchy) with the given name –and inserts instructions to pass object as self parameter a direct call to the known method let class A extends Object { static method foo (x:int) =... static method bar (x:int) =... } class B extends A { static method foo (x:int) =... } var a : A = new A var b : A = new B var c : B = new B in a.foo(3); (* calls foo in class A *) b.foo(3); (* calls foo in class A *) c.bar(3); (* calls bar in class A *) c.foo(3); (* calls foo in class B *)

Dynamic Methods –Method called depends on objects dynamic type During semantic analysis, may be unknown –At run-time, we determine which code to jump to object stores a pointer to its method table (v-table) as well as its object vars –At compile-time, we generate code to look up v-table in object extract method from table jump to method body let class A extends Object { method foo (x:int) =... method bar (x:int) =... } class B extends A { method foo (x:int) =... } var a : A = new A var b : A = new B var c : A = if long-and-tricky-computation then a else b in c.foo(3)

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () }

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () } A a A_f

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () } B a A a A_f B_g

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () } C a B a A a A_f B_g A_f C_g

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () } D a b C a B a A a A_f B_g A_f C_g D_f C_g

Object Layout II (SI) class A extends Object { var a := 0; method f () } class B extends A { method g () } class C extends B { method g () } class D extends C { var b := 0 ; method f () } D a b C a B a A a A_f B_g A_f C_g D_f C_g D a b

Multiple Inheritence Multiple inheritence is trickier to implement than single inheritence because creating objects of a subclass from their subclass by extension on the right doesnt work –if C inherits from both A and B, we cant put As variables at the front and put Bs variables at the front of the object in the same place! –we need to do a global analysis to determine object layout

Object Layout (MI) class A extends Object { var a := 0 } class B extends Object { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends A,B,C { var e := 0 } D a b c e C a d B b c A a d

Object Layout (MI) class A extends Object { var a := 0 } class B extends Object { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends A,B,C { var e := 0 } D a b c e C a d B b c A a d Determine object layout by: global graph coloring! a node for each field name an interference edge between names that coexist in the same class (via inheritence or otherwise)

Object Layout (MI) class A extends Object { var a := 0 } class B extends Object { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends A,B,C { var e := 0 } D a b c e C a d B b c A a d wasted space in every object

Object Layout II (MI) class A extends Object { var a := 0 } class B extends Object { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends A,B,C { var e := 0 } D a b c e C a d B b c A a d wasted space per class a: b: a: d: a: b: c: d: e:

Object Layout II (MI) class A extends Object { var a := 0 } class B extends Object { var b := 0 var c := 0 } class C extends A { var d := 0 } class D extends A,B,C { var e := 0 } B b c A a a: b: To fetch a field using this representation, we: load the first field of the object to get the class descriptor c load M [c + fieldOffset] Note: fieldOffset can be precomputed using global graph coloring as before

A Problem Global analyses are the bane of modern computing –many applications use dynamically linked libraries, mobile code, get patches to fix bugs, etc. –when we dont have the whole program at compile- time, we cant do global analyses! –solution (most of the time): a smart custom linker still tricky when new code is linked dynamically to code that is already running –hence, Java has single inheritence

Other OO Features Down-casts and type tests –Java has casting mechanism (C) x to cast variable x to class C at run time we look up xs dynamic type and determine whether it is a subtype of C these type casts are currently pervasive and a source of both inefficiency and errors soon, Java and C# will be adding parametric polymorphism, a la ML, to make many of these unnecessary casts go away

Other OO Features Protection mechanisms –to encapsulate local state within an object, Java has private protected and public qualifiers private methods/fields cant be called/used outside of the class in which they are defined –during semantic analysis (type checking), the compiler maintains this information in the symbol table for each class

Summary Object-oriented languages provide new challenges for compiler writers –how to find fields and methods –how to make field and method access just as efficient as ordinary function call and variable lookup –lots of ongoing research in OO language implementation tackles these and other interesting questions