Procedure Abstraction VI Runtime structures for OOLs II

Procedure Abstraction VI Run-time structures for OOLs (II) and Wrap-up Copyright 2003, Keith D. Cooper, Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit permission to make copies of these materials for their personal use.

Implementing Object-Oriented Languages Mapping message names to methods • Static mapping, known at compile-time ® Fixed offsets & indirect calls • Dynamic mapping, unknown until run-time ® ( Java, C++) ( Smalltalk) Look up name in class’ table of methods Want uniform placement of standard services (NEW, This is really a data-structures problem • Build a table of function pointers • Use a standard invocation sequence PRINT, …)

Implementing Object-Oriented Languages With static, compile-time mapped classes Class A Class B fee() x band() • i j k fie() bend() foe() bind() y fum() z • • i i j m j k k • a n bond() p • • a b c b c Message dispatch becomes an indirect call through a function table c

Single Inheritance and Dynamic Dispatch • Use prefixing of tables Class Point { self int x, y; public void draw(); public void d 2 o(); } table draw Point: draw x d 2 o Point: d 20 self table draw x d 2 o y rev Class Color. Point extends Point { Color c; public void draw(); public void rev(); } y c Color. Point: draw Color. Point: rev

The Inheritance Hierarchy To simplify object creation, we allow a class to inherit methods from an ancestor, or superclass. The descendant class is called the subclass of its ancestor. The Concept: Method table is an extension of table from One Principle fee() a • fie() One x b • fee() d • • foe() c • x y x • y Two x fie() foe() fum() e • x z Three • B subclass A d B can be used wherever e A is expected ® B may override a method definition from A Subclass provides all the interfaces of superclass,

The Inheritance Hierarchy Two distinct philosophies Static class structure Dynamic class structure • Can map name to code at • Cannot map name to code compile time at compile time • Leads to 1 -level jump vector • Multiple jump vector (1/class) • Copy superclass methods • Must search for method • Fixed offsets & indirect calls • Run-time lookups caching • Less flexible & expressive • Much more expensive to run Impact on name space • Method can see instance variables of self, class, & superclasses • Many different levels where a value can reside In essence, OOL differs from ALL in the shape of its name space AND in the mechanism used to bind names to implementations

Dynamic versus Static Dispatch When must the compiler generate indirect calls for M? • If object O’s type is known at compile time and all of its methods can be resolved at compile time, compiler can generate a direct call. • If object O’s type is not known — for example, due to subtyping — then run-time resolution may be necessary Use function-table pointer from O’s object record ® Generate an indirect call at the “right offset” ® Compiler can generate efficient tables by instantiating function pointer(s) at each class

Dynamic versus Static Dispatch Does the run-time system ever need to resolve method names at run-time? • If the class hierarchy can change at run-time Either rebuild compact function tables at change, or ® Keep the whole hierarchy intact & use caching ® Smalltalk had this problem feature • Run-time name resolution • Extensive caching of results (inline method caches) See Deutsch & Schiffman, “Efficient Implementation of the Smalltalk-80 System”, Conference Record of the 10 th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL), January 1984. (Available through the ACM Digital Library, from Fondren’s web page)

Multiple Inheritance The idea • Allow more flexible sharing of methods & attributes • Relax the inclusion requirement If B is a subclass of A, it need not implement all of A’s methods • Need a linguistic mechanism for specifying partial inheritance Problems when C inherits from both A & B • C’s method table can extend A or B, but not both ® Layout of an object record for C becomes tricky • Other classes, say D, can inherit from C & B ® Adjustments to offsets become complex • Both A & B might provide fum() — which is seen in C ? ® C++ produces a “syntax error” when fum() is used Need a better way to say “inherit”

Multiple Inheritance Example • Use prefixing of storage Class Point { int x, y; } self x y Class Colored. Thing { Color c; } self c Class Color. Point extends Point, Colored. Thing { self x } Does casting work properly? y c

Multiple Inheritance Example • Use prefixing of storage Class Point { int x, y; void draw(); void d 2 o(); } Class CThing { Color c; void rev(); } self draw Point: draw x d 2 o Point: d 20 y self table rev CThing: rev c self Class Cpoint extends Point, CThing { void draw() } table draw x d 2 o y rev table c rev CPoint: draw self +=12

Casting with Multiple Inheritance • Usage as Point: ® No extra action (prefixing does everything) • Usage as CThing: ® Increment self by 12 • Usage as CPoint: Lay out data for CThing at self + 16 ® When calling rev ¨ Call in table points to a trampoline function that adds 12 to self, then calls rev ¨ Ensures that rev, which assumes that self points to a CThing data area, gets the right data ®

Multiple Inheritance (Example) Assume that C inherits fee() from A, fie() from B, & defines both foe() and fum() Object record for an instance of C • A vars fee() • fie() B vars foe() C vars fum() fie() code • Uses trampoline functions • Optimizes well with inlining • Adds overhead where needed (Zero offsets go away) • Folds inheritance into data structure, rather than linkage + offset code This implementation code Trampoline function Assumes static class structure For dynamic, why not rebuild on a change in structure?

Implementing Object-Oriented Languages So, what can an executing method see? (Reprise) • The object’s own attributes & private variables • The attributes & private variables of classes that define it May be many such classes, in many combinations ® Class variables are visible to methods that inherit the class ® • Object defined in the global name space (or scope) ® Objects may contain other objects • Objects that contain their definition ® A class as an instance variable of another class, . . . An executing method might reference any of these Making this work requires compile-time elaboration for static case and run-time elaboration for dynamic case Making it run quickly takes care, planning, and trickery … (later)

Memory Layout Placing run time data structures C o d e 0 S G t l a&o t b i a c l H e a p • Stack & heap share free space • Fixed-size areas together • For compiler, this is the entire S t a c k picture high Alignment & padding • Both languages & machines have alignment restrictions • Place values with identical restrictions next to each other • �Assign offsets from most restrictive to least • Insert padding to match restrictions (if needed)

Impact of Memory Model on Code Shape Memory-to-memory model • Compiler works within constraints of register set • At each statement, compiler ensures demand < k • Each variable has a location in memory • Register allocation becomes an optimization Register-to-register model • Compiler works with an unlimited set of virtual registers • Compiler largely ignores relationship between demand & k • Only allocate memory for spills, parameters, & ambiguous values Complex data structures (arrays) will be assigned to memory Register allocation is needed for correctness (names) ® •

Cache Performance & Relative Offsets Principle: • Two items referenced together Would like them in same cache block, or ® Would like them to map into different cache sets ® • This notion is sometimes called “cache packing” • Manageable problem for two variables • Complexity rises immensely with more variables Cache organization • Virtual address tags cache behavior based on compiler’s model (cache blocks associate by virtual address) • Physical tags no relationship if distance page size

Heap management Allocate( ) & Free( ) • Implementing these requires attention to detail • Watch allocation & free cost, as well as fragmentation • Many classic algorithms (first fit, first fit with rover, best fit) Implicit deallocation • Humans are bad at writing calls to free() • Major source of run-time problems • Solution is to automate deallocation Reference counting + automatic free() ® Mark-sweep style garbage collection ®