Object Type Integrity for C++ Virtual Dispatch

Total Page:16

File Type:pdf, Size:1020Kb

Object Type Integrity for C++ Virtual Dispatch CFIXX: Object Type Integrity for C++ Virtual Dispatch Nathan Burow Derrick McKee Scott A. Carr Mathias Payer Purdue University Purdue University Purdue University Purdue University [email protected] [email protected] [email protected] [email protected] Abstract—C++ relies on object type information for dynamic the program’s control-flow, frequently by redirecting dynamic dispatch and casting. The association of type information to an dispatch [5]. This is a form of code-reuse and indeed Return object is implemented via the virtual table pointer, which is Oriented Programming (ROP) [32], [8] attacks have been stored in the object itself. C++ has neither memory nor type specialized for C++ [33]. To the best of our knowledge, no safety, adversaries may therefore overwrite an object’s type. If existing work fully explores how vulnerable C++’s dynamic the corrupted type is used for dynamic dispatch, the attacker dispatch is to these attacks, or is capable of stopping the full has hijacked the application’s control flow. This vulnerability is widespread and commonly exploited. Firefox, Chrome, and spectrum of attacks on dynamic dispatch. other major C++ applications are network facing, commonly C++ uses dynamic dispatch to implement polymorphism. attacked, and make significant use of dynamic dispatch. Control- A key feature of polymorphism is that objects which inherit Flow Integrity (CFI) is the state of the art policy for efficient mitigation of control flow hijacking attacks. CFI mechanisms from a base class can be up cast to that base class, while still determine statically (i.e., at compile time) the set of functions retaining their own implementations of any virtual methods. that are valid at a given call site, based on C++ semantics. We Put another way, an object’s underlying type – the class it was propose an orthogonal policy, Object Type Integrity (OTI), that allocated as – determines the behavior of dynamic dispatch. dynamically tracks object types. Consequently, instead of allowing Consequently, one call site on a base class can have different a set of targets for each dynamic dispatch on an object, only the behavior depending on the type of the object at runtime. single, correct target for the object’s type is allowed. Dynamic dispatch is used to determine which implementation To show the efficacy of OTI, we present CFIXX, which of the virtual method should be invoked. C++ relies on virtual enforces OTI. CFIXX enforces OTI by dynamically tracking table pointers to implement dynamic dispatch. Virtual table the type of each object and enforcing its integrity against pointers tie an object to its underlying type and thus determine arbitrary writes. CFIXX has minimal overhead on CPU bound the correct target for the dispatch. For dispatch, Object Type applications such as SPEC CPU2006- 4.98%. On key applications Integrity (OTI) enforces that the correct object type is used (the like Chromium, CFIXX has negligible overhead on JavaScript one assigned by the constructor when the object was allocated). benchmarks: 2.03% on Octane, 1.99% on Kraken, and 2.80% on Dynamic dispatch leverages the virtual table pointer to identify JetStream. We show that CFIXX can be deployed in conjunction the type of an object, OTI therefore requires integrity of the with CFI, providing a significant security improvement. virtual table pointer. I. INTRODUCTION Violations of OTI are possible because virtual table pointers are fundamentally required to be in writeable memory. Each Web browsers are among the most commonly used polymorphic object (i.e., an object with virtual methods) needs and most complex applications running on today’s systems. a virtual table pointer, and can exist anywhere in memory. Browsers are responsible for correctly processing arbitrary Consequently, the virtual table pointer has to be included in input in the form of web pages, including large and complex the memory representation of the object. As C++ has neither web applications with a threat model that includes an adversary memory nor type safety, having virtual table pointers in the with (restricted) code execution through JavaScript. Conse- objects exposes them to corruption. Once virtual table pointers quently, browsers are some of the most commonly attacked have been corrupted – and OTI violated – the attacker has programs. The major web browsers (Firefox, Chrome, Safari, successfully corrupted control flow information. The attacker and Internet Explorer/Edge) are written primarily in C++, then forces that object to be used for dynamic dispatch, which does not enforce type safety and is prone to use after hijacking the control flow of the program. Given control over free (UaF) and other memory safety errors. Attackers now the program’s control flow, she can mount a code reuse attack, increasingly use type safety and UaF vulnerabilities to hijack leading to arbitrary execution. Observe that code reuse attacks operate in three stages: (i) Permission to freely reproduce all or part of this paper for noncommercial an initial memory or type safety violation, (ii) corruption of purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited control data, and (iii) the control flow hijack [34]. The current without the prior written consent of the Internet Society, the first-named author state-of-the art for efficiently mitigating code-reuse attacks (for reproduction of an entire paper only), and the author’s employer if the is Control-Flow Integrity (CFI) [3], [29], [37], [9], which paper was prepared within the scope of employment. mitigates the third step of the attack by limiting the control NDSS ’18, 18-21 February 2018, San Diego, CA, USA Copyright 2018 Internet Society, ISBN 1-1891562-49-5 flow to paths that are valid in the program’s control flow http://dx.doi.org/10.14722/ndss.2018.23279 graph. CFI mechanisms specialized to deal with C++ dynamic dispatch [37], [9] leverage the class hierarchy when computing results, our prototype OTI enforcement mechanism, CFIXX, the set of valid targets for virtual dispatch sites, increasing is open source: https://github.com/HexHive/CFIXX. precision. Despite the precision added by class hierarchy information, the target set can be large enough for the attacker Our contributions are: to find sufficient gadgets to achieve her desired goals [11], 1) A new defense policy, Object Type Integrity (OTI), [18], [10], [33]. Each overridden virtual function increases which mitigates all known attacks on dynamic dis- imprecision, as all implementations must be in the same target patch. set. For large C++ applications, such as web browsers, these 2) A defense mechanism that enforces OTI, CFIXX, and sets are surprisingly large in practice, see Section III-C for an evaluation of the prototype on SPEC CPU2006– details. including libc++, and Chromium. CFI’s weakness – over-approximate target sets – is not 3) A demonstration of how to efficiently use MPX to fundamental to the problem of preventing dynamic dispatch integrity protect arbitrary regions of memory. from being used for code-reuse attacks. At runtime there is only one correct target for any virtual call. The correct target II. C++ DYNAMIC DISPATCH is dictated by the dynamic type of the object used to make the virtual call. The alias analysis problem prevents static Dynamic dispatch is a key part of polymorphism in C++, analysis from determining the dynamic type of the object at allowing classes to override implementations of virtual func- the virtual call site. Indeed, any case where static analysis can tions that they inherit. Figure 1 contains a simple code exam- determine the exact type, as opposed to a set of types, should ple illustrating virtual functions, overriding implementations, be devirtualized as an optimization. Consequently, a security and the associated memory layout. C++ implements dynamic mechanism must leverage runtime information to correctly dispatch by maintaining a mapping from each object to its track an object’s type and secure dynamic dispatch on that underlying type – and thus the true implementation of the object, as opposed to the static, compile time information that object’s virtual functions. At each virtual call site, two things CFI policies rely on. occur: 1) the appropriate function is determined from the object’s virtual table, and 2) an indirect call to that function is We propose a new defense policy, Object Type Integrity made. The correctness of dynamic dispatch thus depends on (OTI) which guarantees that an object’s type cannot be mod- the integrity of the mapping from an object to its underlying ified by an adversary, i.e., integrity protecting it, thereby type, i.e., object type integrity. guaranteeing the correctness of dynamic dispatch on that object. OTI thus mitigates the second step of a code-reuse The object type mapping at the core of dynamic dispatch is attack by preventing key application control flow data from implemented by creating a virtual table for each polymorphic being corrupted. OTI tracks the assigned type for every object class. The virtual table consists of function pointers to the at runtime. Consequently, when the object’s type is used for a correct implementation of each of the class’s virtual functions. dynamic dispatch, OTI can verify that the type is uncorrupted. The compiler populates the virtual tables with the correct Further, OTI requires that each object has a known type, thus function pointers, and is responsible for managing the virtual preventing the attacker from injecting objects [33], and using function name to virtual table index mapping. The virtual them for dynamic dispatch. OTI distinguishes itself from CFI tables are fixed at compile time, and mapped read only at by intervening one stage earlier in the attack, and by being runtime. Each object of a class is given a virtual table pointer fully precise, instead of relying on target sets.
Recommended publications
  • MANNING Greenwich (74° W
    Object Oriented Perl Object Oriented Perl DAMIAN CONWAY MANNING Greenwich (74° w. long.) For electronic browsing and ordering of this and other Manning books, visit http://www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. 32 Lafayette Place Fax: (203) 661-9018 Greenwich, CT 06830 email: [email protected] ©2000 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Library of Congress Cataloging-in-Publication Data Conway, Damian, 1964- Object oriented Perl / Damian Conway. p. cm. includes bibliographical references. ISBN 1-884777-79-1 (alk. paper) 1. Object-oriented programming (Computer science) 2. Perl (Computer program language) I. Title. QA76.64.C639 1999 005.13'3--dc21 99-27793 CIP Manning Publications Co. Copyeditor: Adrianne Harun 32 Lafayette
    [Show full text]
  • Improving Virtual Function Call Target Prediction Via Dependence-Based Pre-Computation
    Improving Virtual Function Call Target Prediction via Dependence-Based Pre-Computation Amir Roth, Andreas Moshovos and Gurindar S. Sohi Computer Sciences Department University of Wisconsin-Madison 1210 W Dayton Street, Madison, WI 53706 {amir, moshovos, sohi}@cs.wisc.edu Abstract In this initial work, we concentrate on pre-computing virtual function call (v-call) targets. The v-call mecha- We introduce dependence-based pre-computation as a nism enables code reuse by allowing a single static func- complement to history-based target prediction schemes. tion call to transparently invoke one of multiple function We present pre-computation in the context of virtual implementations based on run-time type information. function calls (v-calls), a class of control transfers that As shown in Table 1, v-calls are currently used in is becoming increasingly important and has resisted object-oriented programs with frequencies ranging from conventional prediction. Our proposed technique 1 in 200 to 1000 instructions (4 to 20 times fewer than dynamically identifies the sequence of operations that direct calls and 30 to 150 times fewer than conditional computes a v-call’s target. When the first instruction in branches). V-call importance will increase as object-ori- such a sequence is encountered, a small execution ented languages and methodologies gain popularity. For engine speculatively and aggressively pre-executes the now, v-calls make an ideal illustration vehicle for pre- rest. The pre-computed target is stored and subse- computation techniques since their targets are both diffi- quently used when a prediction needs to be made. We cult to predict and easy to pre-compute.
    [Show full text]
  • Valloy – Virtual Functions Meet a Relational Language
    VAlloy – Virtual Functions Meet a Relational Language Darko Marinov and Sarfraz Khurshid MIT Laboratory for Computer Science 200 Technology Square Cambridge, MA 02139 USA {marinov,khurshid}@lcs.mit.edu Abstract. We propose VAlloy, a veneer onto the first order, relational language Alloy. Alloy is suitable for modeling structural properties of object-oriented software. However, Alloy lacks support for dynamic dis- patch, i.e., function invocation based on actual parameter types. VAlloy introduces virtual functions in Alloy, which enables intuitive modeling of inheritance. Models in VAlloy are automatically translated into Alloy and can be automatically checked using the existing Alloy Analyzer. We illustrate the use of VAlloy by modeling object equality, such as in Java. We also give specifications for a part of the Java Collections Framework. 1 Introduction Object-oriented design and object-oriented programming have become predom- inant software methodologies. An essential feature of object-oriented languages is inheritance. It allows a (sub)class to inherit variables and methods from su- perclasses. Some languages, such as Java, only support single inheritance for classes. Subclasses can override some methods, changing the behavior inherited from superclasses. We use C++ term virtual functions to refer to methods that can be overridden. Virtual functions are dynamically dispatched—the actual function to invoke is selected based on the dynamic types of parameters. Java only supports single dynamic dispatch, i.e., the function is selected based only on the type of the receiver object. Alloy [9] is a first order, declarative language based on relations. Alloy is suitable for specifying structural properties of software. Alloy specifications can be analyzed automatically using the Alloy Analyzer (AA) [8].
    [Show full text]
  • Inheritance & Polymorphism
    6.088 Intro to C/C++ Day 5: Inheritance & Polymorphism Eunsuk Kang & JeanYang In the last lecture... Objects: Characteristics & responsibilities Declaring and defining classes in C++ Fields, methods, constructors, destructors Creating & deleting objects on stack/heap Representation invariant Today’s topics Inheritance Polymorphism Abstract base classes Inheritance Types A class defines a set of objects, or a type people at MIT Types within a type Some objects are distinct from others in some ways MIT professors MIT students people at MIT Subtype MIT professor and student are subtypes of MIT people MIT professors MIT students people at MIT Type hierarchy MIT Person extends extends Student Professor What characteristics/behaviors do people at MIT have in common? Type hierarchy MIT Person extends extends Student Professor What characteristics/behaviors do people at MIT have in common? �name, ID, address �change address, display profile Type hierarchy MIT Person extends extends Student Professor What things are special about students? �course number, classes taken, year �add a class taken, change course Type hierarchy MIT Person extends extends Student Professor What things are special about professors? �course number, classes taught, rank (assistant, etc.) �add a class taught, promote Inheritance A subtype inherits characteristics and behaviors of its base type. e.g. Each MIT student has Characteristics: Behaviors: name display profile ID change address address add a class taken course number change course classes taken year Base type: MITPerson
    [Show full text]
  • Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages
    Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages Corky Cartwright Mar 10-19, 2021 Overview I • In OO languages, OO data values (except for designated non-OO types) are special records [structures] (finite mappings from names to values). In OO parlance, the components of record are called members. • Some members of an object may be functions called methods. Methods take this (the object in question) as an implicit parameter. Some OO languages like Java also support static methods that do not depend on this; these methods have no implicit parameters. In efficient OO language implementations, method members are shared since they are the same for all instances of a class, but this sharing is an optimization in statically typed OO languages since the collection of methods in a class is immutable during program evaluation (computation). • A method (instance method in Java) can only be invoked on an object (the receiver, an implicit parameter). Additional parameters are optional, depending on whether the method expects them. This invocation process is called dynamic dispatch because the executed code is literally extracted from the object: the code invoked at a call site depends on the value of the receiver, which can change with each execution of the call. • A language with objects is OO if it supports dynamic dispatch (discussed in more detail in Overview II & III) and inheritance, an explicit taxonomy for classifying objects based on their members and class names where superclass/parent methods are inherited unless overridden. • In single inheritance, this taxonomy forms a tree; • In multiple inheritance, it forms a rooted DAG (directed acyclic graph) where the root class is the universal class (Object in Java).
    [Show full text]
  • CSE 307: Principles of Programming Languages Classes and Inheritance
    OOP Introduction Type & Subtype Inheritance Overloading and Overriding CSE 307: Principles of Programming Languages Classes and Inheritance R. Sekar 1 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Topics 1. OOP Introduction 3. Inheritance 2. Type & Subtype 4. Overloading and Overriding 2 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Section 1 OOP Introduction 3 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding OOP (Object Oriented Programming) So far the languages that we encountered treat data and computation separately. In OOP, the data and computation are combined into an “object”. 4 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP more convenient: collects related information together, rather than distributing it. Example: C++ iostream class collects all I/O related operations together into one central place. Contrast with C I/O library, which consists of many distinct functions such as getchar, printf, scanf, sscanf, etc. centralizes and regulates access to data. If there is an error that corrupts object data, we need to look for the error only within its class Contrast with C programs, where access/modification code is distributed throughout the program 5 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP (Continued) Promotes reuse. by separating interface from implementation. We can replace the implementation of an object without changing client code. Contrast with C, where the implementation of a data structure such as a linked list is integrated into the client code by permitting extension of new objects via inheritance. Inheritance allows a new class to reuse the features of an existing class.
    [Show full text]
  • Inheritance | Data Abstraction Z Information Hiding, Adts | Encapsulation | Type Extensibility for : COP 3330
    OOP components Inheritance | Data Abstraction z Information Hiding, ADTs | Encapsulation | Type Extensibility For : COP 3330. z Operator Overloading Object oriented Programming (Using C++) | Inheritance http://www.compgeom.com/~piyush/teach/3330 z Code Reuse | Polymorphism Piyush Kumar “Is a” Vs “Has a” Another Example UML Vehicle Inheritance class Car : public Vehicle { public: Considered an “Is a” class relationship // ... Car }; e.g.: An HourlyEmployee “is a” Employee A Convertible “is a” Automobile We state the above relationship in several ways: * Car is "a kind of a" Vehicle A class contains objects of another class * Car is "derived from" Vehicle as it’s member data * Car is "a specialized" Vehicle * Car is the "subclass" of Vehicle Considered a “Has a” class relationship * Vehicle is the "base class" of Car * Vehicle is the "superclass" of Car (this not as common in the C++ community) e.g.: One class “has a” object of another class as it’s data Virtual Functions Virtual Destructor rule | Virtual means “overridable” | If a class has one virtual function, you | Runtime system automatically invokes want to have a virtual destructor. the proper member function. | A virtual destructor causes the compiler to use dynamic binding when calling the destructor. | Costs 10% to 20% extra overhead compared to calling a non-virtual | Constructors: Can not be virtual. You function call. should think of them as static member functions that create objects. 1 Pure virtual member Pure virtual. functions. | A pure virtual member function is a | Specified by writing =0 after the member function that the base class function parameter list. forces derived classes to provide.
    [Show full text]
  • Dynamic Dispatch
    CS 3110 Lecture 24: Dynamic Dispatch Prof. Clarkson Spring 2015 Today’s music: "Te Core" by Eric Clapton Review Current topic: functional vs. object-oriented programming Today: • Continue encoding objects in OCaml • Te core of OOP – dynamic dispatch – sigma calculus Review: key features of OOP 1. Encapsulation 2. Subtyping 3. Inheritance 4. Dynamic dispatch Review: Counters class Counter {! protected int x = 0;! public int get() { return x; }! public void inc() { x++; }! }! Review: Objects • Type of object is record of functions !type counter = {! !get : unit -> int;! !inc : unit -> unit;! !} • Let-binding hides internal state (with closure) !let x = ref 0 in {! !get = (fun () -> !x);! !inc = (fun () -> x := !x+1);! !}! Review: Classes • Representation type for internal state: !type counter_rep = {! !!x : int ref;! !}! • Class is a function from representation type to object: !let counter_class (r:counter_rep) = {! !!get = (fun () -> !(r.x));! !!inc = (fun () -> (r.x := !(r.x) + 1));! !}! • Constructor uses class function to make a new object: !let new_counter () =! !!let r = {x = ref 0} in! ! !counter_class r !! Review: Inheritance • Subclass creates an object of the superclass with the same internal state as its own – Bind resulting parent object to super • Subclass creates a new object with same internal state • Subclass copies (inherits) any implementations it wants from superclass 4. DYNAMIC DISPATCH This class SetCounter {! protected int x = 0;! public int get() { return x; }! public void set(int i) { x = i; }! public void inc()
    [Show full text]
  • Virtual Function in C++
    BCA SEMESTER-II Object Oriented Programming using C++ Paper Code: BCA CC203 Unit :4 Virtual Function in C++ By: Ms. Nimisha Manan Assistant Professor Dept. of Computer Science Patna Women’s College Virtual Function When the same function name is defined in the base class as well as the derived class , then the function in the base class is declared as Virtual Function. Thus a Virtual function can be defined as “ A special member function that is declared within a base class and redefined by a derived class is known as virtual function”. To declare a virtual function, in the base class precede the function prototype with the keyword virtual. Syntax for defining a virtual function is as follows:- virtual return_type function_name(arguments) { ------ } Through virtual function, functions of the base class can be overridden by the functions of the derived class. With the help of virtual function, runtime polymorphism or dynamic polymorphism which is also known as late binding is implemented on that function. A function call is resolved at runtime in late binding and so compiler determines the type of object at runtime. Late binding allows binding between the function call and the appropriate virtual function (to be called) to be done at the time of execution of the program. A class that declares or inherits a virtual function is called a polymorphic class. For Example: Virtual void show() { Cout<<”This is a virtual function”; } Implementation of Dynamic Polymorphism through Virtual Function Dynamic Polymorphism is implemented through virtual function by using a single pointer to the base class that points to all the objects of derived class classes.
    [Show full text]
  • All Your Base Transactions Belong to Us
    All Your Base Transactions Belong to Us Jeff Vance, Alex Melikian Verilab, Inc Austin, TX, USA www.verilab.com ABSTRACT Combining diverse transaction classes into an integrated testbench, while common practice, typically produces a cumbersome and inadequate setup for system-level verification. UVM sequence item classes from different VIPs typically have different conventions for storing, printing, constraining, comparing, and covering behavior. Additionally, these classes focus on generic bus aspects and lack context for system coverage. This paper solves these problems using the mixin design pattern to supplement all transaction classes with a common set of metadata and functions. A mixin solution can be applied to any project with minimal effort to achieve better visibility of system-wide dataflow. This setup enables significantly faster debug time, higher quality bug reports, and increases the efficiency of the verification team. Combining a mixin with an interface class results in a powerful and extensible tool for verification. We show how to define more accurate transaction coverage with extensible covergroups that are reusable with different transaction types. Scoreboard complexity is reduced with virtual mixin utility methods, and stimulus is managed with shared constraints for all interface traffic. Finally, we show this solution can be retrofitted to any legacy UVM testbench using standard factory overrides. SNUG 2019 Table of Contents 1. Introduction ...........................................................................................................................................................................
    [Show full text]
  • Importance of Virtual Function, Function Call Binding, Virtual Functions, Implementing Late Binding, Need for Virtual Functions
    Object Oriented Programming Using C++ Unit 7th Semester 4th Importance of virtual function, function call binding, virtual functions, implementing late binding, need for virtual functions, abstract base classes and pure virtual functions, virtual destructors _______________________________________________________________________________ Importance of virtual function: A virtual function is a member function that is declared within a base class and redefined by a derived class. To create virtual function, precede the function’s declaration in the base class with the keyword virtual. When a class containing virtual function is inherited, the derived class redefines the virtual function to suit its own needs. Virtual Functions are used to support "Run time Polymorphism". You can make a function virtual by preceding its declaration within the class by keyword 'virtual'. When a Base Class has a virtual member function, any class that inherits from the Base Class can redefine the function with exactly the same prototype i.e. only functionality can be redefined, not the interface of the function. A Base class pointer can be used to point to Base Class Object as well as Derived Class Object. When the virtual function is called by using a Base Class Pointer, the Compiler decides at Runtime which version of the function i.e. Base Class version or the overridden Derived Class version is to be called. This is called Run time Polymorphism. What is Virtual Function? A virtual function is a member function within the base class that we redefine in a derived class. It is declared using the virtual keyword. When a class containing virtual function is inherited, the derived class redefines the virtual function to suit its own needs.
    [Show full text]
  • Specialising Dynamic Techniques for Implementing the Ruby Programming Language
    SPECIALISING DYNAMIC TECHNIQUES FOR IMPLEMENTING THE RUBY PROGRAMMING LANGUAGE A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences 2015 By Chris Seaton School of Computer Science This published copy of the thesis contains a couple of minor typographical corrections from the version deposited in the University of Manchester Library. [email protected] chrisseaton.com/phd 2 Contents List of Listings7 List of Tables9 List of Figures 11 Abstract 15 Declaration 17 Copyright 19 Acknowledgements 21 1 Introduction 23 1.1 Dynamic Programming Languages.................. 23 1.2 Idiomatic Ruby............................ 25 1.3 Research Questions.......................... 27 1.4 Implementation Work......................... 27 1.5 Contributions............................. 28 1.6 Publications.............................. 29 1.7 Thesis Structure............................ 31 2 Characteristics of Dynamic Languages 35 2.1 Ruby.................................. 35 2.2 Ruby on Rails............................. 36 2.3 Case Study: Idiomatic Ruby..................... 37 2.4 Summary............................... 49 3 3 Implementation of Dynamic Languages 51 3.1 Foundational Techniques....................... 51 3.2 Applied Techniques.......................... 59 3.3 Implementations of Ruby....................... 65 3.4 Parallelism and Concurrency..................... 72 3.5 Summary............................... 73 4 Evaluation Methodology 75 4.1 Evaluation Philosophy
    [Show full text]