28
Implementation I MPLEMENTATION Muhammad Adil Raja Roaming Researchers, Inc. cbna April 24, 2015

Implementation

Embed Size (px)

Citation preview

Implementation

IMPLEMENTATION

Muhammad Adil Raja

Roaming Researchers, Inc.

cbna

April 24, 2015

Implementation

OUTLINE I

1 INTRODUCTION

2 REFERENCES

Implementation

Introduction

INTRODUCTION

Topics covered in this chapter include:Compilers vs Interpreters.The Receiver as Argument.Inherited Methods.The problem of Multiple Inheritance.Overridden Methods.Name Encoding.Dispatch Tables.Bytecode Interpreters.Just in Time Compilation.

Implementation

Introduction

INSPIRATION

Design patterns speed the process of finding a solution, byeliminating the need to reinvent well-known and provensolutions.Just as important, design patterns provide a vocabularywith which to discuss the space of possible design choices.This vocabulary is termed a pattern language.

Implementation

Introduction

TWO GENERAL APPROACHES TO IMPLEMENTATION

Compilers - translated into basic machine code, sourcecode not available at run-time, generally very efficient.Interpreters - translated into intermediate representation,source code available for reference at run-time, generallysomewhat less efficient.Endpoints are clear, but there are lots of grey areas in themiddle.Java JIT systems are one of those grey areas betweencompilers and interpreters.

Implementation

Introduction

A method is eventually invoked just like any other function.This means that the receiver just be passed as anargument.Traditionally, it is passed as the first argument.This means a method call, such asaCardPile->addCard (currentCard)Is translated intoaddCard (aCardPile, currentCard)(This is ignoring the method lookup process, which we willdiscuss shortly).

Implementation

Introduction

On the other side, the receiver pseudo-variable is just aformal argument:Instead of

EXAMPLE

void CardPi le : : addCard ( Card ∗ aCard ) {. . .

}

We have:

void CardPi le : : addCard ( Card ∗ aCard ) {. . .

}

The first argument can then be used to access data membersand other methods.

Implementation

Introduction

NO-VIRTUAL METHODS

In languages that permit both virtual and non-virtualmethods (such as C++) a non-virtual method is translatedinto a simple procedure call.The receiver is made into the first argument.The name is encoded to make it unique.

Implementation

Introduction

NAME ENCODING

Different classes are allowed to have functions with thesame name.Some languages (C++) even permit multiple functions withthe same name within a class.Yet linkers usually want every function to have a uniquename.Solution - generate an internal name that encodes bothclass name, function name, and argument types.Example: Foo::Bar_int_float_intAn encoded name is sometimes called a mangled name.You will sometimes see mangled names in error messagesgenerated by a linker.

Implementation

Introduction

INHERITED METHODS I

Now consider those methods defined in a parent class, butused by a child class.

How is it that this mechanism can work?

Normally you cannot change the types of arguments (recallthat the receiver is just an argument).

Solution is that the data associated with an instance of achild class is an extension of the data associated with theparent class.

This means that data fields in the parent class will be foundat the same offset in the child class.

Implementation

Introduction

INHERITED METHODS II

FIGURE : Inherited methods.

Implementation

Introduction

A PROBLEM WITH MULTIPLE INHERITANCE

The idea that a child is an extension of the parent explainsone of the most vexing problems in the implementation ofmultiple inheritance.A child can extend one parent, or the other, but not both.That is the offset of data fields in the child cannotsimultaneously match both parents.

FIGURE : A problem with multiple inheritance.

Implementation

Introduction

SLICING PROBLEM

The idea that a child can extend the data area of the parentalso makes it difficult to support both the following goals.The goal of keeping memory on the stack, which is laid outat compile timeThe goal of supporting the polymorphic variable, which canhold an instance of the child class at run time.Most OO languages uphold (2) and abandon (1), C++ is anexception in that it upholds (1) and therefore abandons (2).

Implementation

Introduction

OVERRIDEN METHODS

We next consider those methods that are defined in aparent class, and overridden in a child class.Problem, how can a polymorphic method invocation findthe right method?Note that the right method can change during the course ofexecution, even for the same method call.

EXAMPLE

CardPi le ∗ aCardPi le = new DiscardP i le ( ) ;Card ∗ aCard = . . . ;

aCardPile−>addCard ( aCard ) ; / / how to f i n d the r i g h t method

Implementation

Introduction

SOLUTION – A VIRTUAL METHOD

The solution is that every object contains an extra hiddendata field.This data field points to an array of pointers to functions.The array is determined by the current dynamic type, andis shared by all instances of the class.The offset of each method can be determined at compiletime.

FIGURE : Solution.

Implementation

Introduction

INSTANCES SHARE THE SAME VIRTUAL METHOD

Two instances of a class will share the same virtualmethod table.

FIGURE : Example.

Implementation

Introduction

METHOD CALLS BECOME INDEXED OFFSETS

Each object maintains a pointer to a table, called the virtualmethod table.Virtual methods are identified by a fixed address in thistable.A method call, such as:A.foo(B, C)is translated into(* A.virTable[idx])(A, B, C)

Implementation

Introduction

BUILDING A VIRTUAL TABLE FOR A SUBCLASS

When a subclass is created, a new virtual method table isgenerated.Methods that are inherited point to the same function asthe parent class. (and are found in the same offset in thevirtual method table).Methods that are overridden occupy the same offsetlocation, but point to the new function, instead of theversion in the parent class.

FIGURE : Virtual table.

Implementation

Introduction

VIRTUAL METHOD TABLE FOR SUBCLASSES

FIGURE : Virtual method table.

Implementation

Introduction

ELIMINATION OF VIRTUAL CALLS

Even though the overhead of a virtual call is small, it canstill add up.If the (dynamic) class of the receiver is know, a virtual callcan simply become an ordinary procedure call.Good optimizing compiles spend a considerable amount oftime tracing possible execution flows to gather thisinformation.Sometimes methods can even be expanded in-line at thepoint of call.

Implementation

Introduction

DISPATCH TABLES

In languages without static typing it is not practical to use avirtual table, since such a table would need to encode allmethods, not simply those in a given class hierarchy.An alternative technique uses a pointer to a list ofselector/method pairs.When a method is invoked, a run-time search is performedto match the method being called with the list of knownselectors, until an appropriate method is found.In Objective-C the messages. is translated into:objc_msgSend(neighbor, “checkrow:column:”, row,column)

Implementation

Introduction

AN OBJECT AND ITS DISPATCH TABLE

FIGURE : Dispatch table.

An important difference is that the dispatch table issearched at run-time, not at compile time.Objective-C uses a linear list for the table, Smalltalkgenerally uses a balanced search tree, but the idea issimilar.

Implementation

Introduction

METHOD CACHE

In order to avoid the cost of a dynamic search of dispatchtables, a single global cache can be used to holdfrequently invoked methods.The cache is used as a large hash table.Prior to searching a dispatch table, the a single hashedentry is examined - if it matches the selector being sought,the method is used, if not the dispatch table is searchedand the new entry replaces the value in the hash table.Assuming a good hash function is used, efficiency can bevery high.

Implementation

Introduction

THE MESSAGING FUNCTION CHECKING THE CACHE

FIGURE : The messaging funciton checking the cache.

Implementation

Introduction

BYTECODE INTERPRETERS

An implementation technique that is widely used(Smalltalk, Java)Program is compiled into an “assembly language” for animaginary machine.Since this assembly code is often represented by a stringof bytes, it is called bytecode.Since the machine is imaginary, can run on any platform.But it must be simulated (by a virtual machine) and henceyou pay an execution time cost.

Implementation

Introduction

BYTES IN LITTLE SMALLTALK SYSTEM

FIGURE : The bytes in little Smalltalk system.

Implementation

Introduction

JUST IN TIME COMPILERS

A currently popular mix between compilers andinterpreters.Key idea, first time a method is executed, translate thebytecode into native machine code.Gives fast execution time, pay penalty for translation (andanalysis if you want to do a good job).Currently very popular with Java systems.

Implementation

References

REFERENCES

Images and content for developing these slides have beentaken from the follwoing book with the permission of theauthor.An Introduction to Object Oriented Programming, TimothyA. Budd.This presentation is developed with Beamer:

JuanLesPins, spruce.