DOCSLIB.ORG

Broom: Sweeping out Garbage Collection from Big Data Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Broom: Sweeping out Garbage Collection from Big Data Systems Broom: sweeping out Garbage Collection from Big Data systems Ionel Gog∗ Jana Giceva†∗ Malte Schwarzkopf Kapil Vaswani‡ Dimitrios Vytiniotis‡ Ganesan Ramalingan‡ Manuel Costa‡ Derek Murray?} Steven Hand?} Michael Isard? University of Cambridge † ETH Zurich ‡ Microsoft Research ? Unaffiliated ∗ parts of the work were done while at Microsoft Research Silicon Valley } now at Google, Inc. Abstract form event-based processing of arriving input data, and therefore behave as independent actors. For example, Many popular systems for processing “big data” are im- at any one time, MapReduce runs a “map” or “reduce” plemented in high-level programming languages with function (i.e., operator) in each task [5], Dryad [11] and automatic memory management via garbage collection Naiad [15] execute a “vertex” per worker thread, and (GC). However, high object churn and large heap sizes Spark runs an “action” per task [22]. Each data-flow op- put severe strain on the garbage collector. As a result, ap- erator’s objects live at most as long as the operator itself. plications underperform significantly: GC increases the Moreover, they are often grouped in logical batches – runtime of typical data processing tasks by up to 40%. e.g., according to keys or timestamps – that can be freed We propose to use region-based memory management atomically. This architecture presents an opportunity to instead of GC in distributed data processing systems. In revisit standard memory-management, because: these systems, many objects have clearly defined life- times. Hence, it is natural to allocate these objects in 1. Actors explicitly share state via message-passing. fate-sharing regions, obviating the need to scan a large 2. The state held by actors consists of many fate- heap. Regions can be memory-safe and could be in- sharing objects with common lifetimes. ferred automatically. Our initial results show that region- 3. End-users only supply code fragments to system- based memory management reduces emulated Naiad ver- defined operators, which makes automatic program tex runtime by 34% for typical data analytics jobs. transformations and region annotations practical. In §3, we illustrate these points with reference to Naiad. 1 Introduction Region-based memory management [19] works well Memory-managed languages dominate the landscape for sets of related objects in the absence of implicit shar- of systems for computing with “big data”: Hadoop, ing. While writing programs using regions is difficult in Spark [22], DryadLINQ [21] and Naiad [15] are only the general case, this old concept is a good fit for the some examples of systems running atop a Java Virtual restricted domain of distributed data processing systems Machine (JVM) or the .NET common language runtime (§4). In addition, region-based allocation can offer mem- (CLR). Managed languages are attractive as they of- ory safety and may be as transparent to the user as GC- fer strong typing, automated memory management and based memory management. We sketch how this can be higher-order functions. These features improve the pro- achieved in a distributed data processing system in §5. ductivity of system developers and end-users. Using Broom, a proof-of-concept implementation of However, these benefits do not come for free. Data region-based memory allocation for Naiad vertices, we processing tasks stress the runtime GC by allocating a show that region-based memory management eliminates large number of objects [4, 17]. This results in long the overheads of GC and improves execution time by up GC pauses that reduce application throughput or cause to 34% in memory-intensive operators (§6). “straggler” tasks [14, 18]. In §2, we show that the impact 2 Motivation of GC on job runtime can range between 20 and 40%. In this paper, we argue that a different approach can be We illustrate the effect of GC on Naiad’s performance used in distributed data processing systems. Their oper- using two simple experiments: ation is highly structured: most such systems are based 1. We measure the fraction of job runtime spent in GC on an implicit or explicit graph of stateful data-flow op- for two data-intensive batch jobs: TPC-H Q17 and erators executed by worker threads. These operators per- a join-heavy business analytics workflow (§2.1). 50 24 TPC-H Q17 22 40 shopper 20 18 30 16 20 14 12 10 10 8 Time spent on GC [%] 0 Naiad process ID 6 4 8 16 32 64 128 256 4 Young generation heap size [MB; log2] 2 0 Figure 1: The Naiad TPC-H Q17 and “shopper” work- 100 200 300 400 500 600 700 800 900 flows spend 20–40% of their total runtime on GC, inde- Experiment time [ms] pendent of the young generation heap size. Figure 3: Trace of incremental strongly connected com- Minor Major ponents in 24 parallel Naiad processes: uncoordinated 20001.0 80 GC pauses (orange and green bars) delay synchroniza- 15000.8 TPC-H Q17 60 tion barriers (gray vertical lines). 0.6 shopper 1000 40 0.4 5000.2 20 Collections (where many objects die young), but the increased young 0.0 0 generation heap size does not help TPC-H Q17 (which 0.04 8 0.2 0.4 04.6 8 0.8 1.0 16 32 64 16 32 64 128 256 128 256 uses stateful JOINs). In fact, the number of minor col- Young generation heap size [MB; log2] lections in TPC-H Q17 increases with young generation heap size as they are traded for major ones (Figure2). Figure 2: Increasing the young generation heap trades This experiment looked at the GC behavior of a sin- more minor collections for fewer major collections in gle data-intensive process that does not communicate. In TPC-H, and reduces total collections for “shopper”. the next experiment, we show that the problem is exacer- bated when dependencies exist between processes. 2. We measure the effects of GC stalls when com- 2.2 Synchronized iterative workflow puting strongly connected components, an iterative We run an incremental strongly connected components workflow with frequent synchronization (§2.2). workflow on a graph of 15M vertices and 80M edges. We run Naiad v0.4 on Linux using Mono v2.10.8.1 with Each incremental step changes one random edge in the the generational GC (sgen) enabled. graph. The computation synchronizes all nodes after ev- 2.1 Batch processing workflows ery graph change. We collect a trace of 24 Naiad pro- cesses on four machines (six per machine) by logging the We run two typical batch processing workflows with high timestamps of the synchronization steps and the times at object churn on a single machine.1 The first is query 17 which the processes run their GC. from the TPC-H benchmark and the second is “shopper”, Figure3 shows a subset of the trace, with each gray a business intelligence workflow that selects users from vertical bar corresponding to a synchronization step at the same country who bought a specific product (a JOIN– the end of an iteration. GC pauses are shown as horizon- SELECT–JOIN workflow). In these experiments, Naiad tal bars for major (orange) and minor (green) collections. uses eleven worker threads on the 12-core machine. It is evident that GC invocations sometimes delay a syn- With the default GC configuration, we found that the chronization by tens of milliseconds. TPC-H workflow spends around 25% of its runtime in It is also worth observing that a GC in one process is GC, while the “shopper” workflow reaches about 37% occasionally immediately followed by another GC in a (Figure1). This makes sense: “shopper” generates many different process (e.g. at times 170–180, 430–460, 530– small objects that are subsequently freed in minor col- 560 and 720–750). This occurs because some changes lections of the 4 MB young generation heap. Increasing to the graph affect state in several processes. Down- the size of the young generation heap reduces the num- stream processes may trigger a GC as soon as they re- ber of objects promoted to the next generation in “shop- ceive messages from upstream ones that have just fin- per”, and thus the overall number of collections (Fig- ished their GC. In other words, the GCs are effectively ure2). This reduces the time spent on GC for “shopper” serialized when a parallel execution would offer better 1AMD Opteron 4243 (12× 3.1 GHz) with 64 GB of DDR3-1600. performance. 3 Case study: Naiad 1 public class AggregateActor { We illustrate the memory management patterns common 2 private Dictionary<Time, Dictionary<K, V>> state; in distributed data processing by example of Naiad. List- 3 4 public void OnReceive(Time time, Message msg) { ing1 shows the code of the Naiad Aggregate vertex 5 if (state[time] == null){ that groups and aggregates input data. The inputs to 6 state[time] = new Dictionary<K,V>(); the vertex are batched in Message objects, each asso- 7 NotifyAt(time); 8 } ciated with a logical timestamp. The results of the ag- 9 foreach (var entry in msg) { gregation are stored in a dictionary keyed by the logical 10 var key = SelectKey(entry); timestamp (line 2). Upon receiving a message, Naiad 11 state[time][key] = calls the user-provided OnReceive method (ln. 4). The 12 Aggregate(state[time][key], entry); 13 } method processes the input and applies the Aggregate 14 } function to each entry (ln. 12), storing the results. Fi- 15 public void OnNotify(Time time) { nally, the OnNotify method is called once the actor is 16 // Remove state for timestamp time guaranteed to receive no more messages with a logical 17 state.remove(time); 18 Send(outgoingMsg); timestamp less than or equal to the one passed (ln.
Load more

Recommended publications
  • An In-Depth Study with All Rust Cves
    Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs HUI XU, School of Computer Science, Fudan University ZHUANGBIN CHEN, Dept. of CSE, The Chinese University of Hong Kong MINGSHEN SUN, Baidu Security YANGFAN ZHOU, School of Computer Science, Fudan University MICHAEL R. LYU, Dept. of CSE, The Chinese University of Hong Kong Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start usingthe language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code.
    [Show full text]
  • Project Snowflake: Non-Blocking Safe Manual Memory Management in .NET
    Project Snowflake: Non-blocking Safe Manual Memory Management in .NET Matthew Parkinson Dimitrios Vytiniotis Kapil Vaswani Manuel Costa Pantazis Deligiannis Microsoft Research Dylan McDermott Aaron Blankstein Jonathan Balkind University of Cambridge Princeton University July 26, 2017 Abstract Garbage collection greatly improves programmer productivity and ensures memory safety. Manual memory management on the other hand often delivers better performance but is typically unsafe and can lead to system crashes or security vulnerabilities. We propose integrating safe manual memory management with garbage collection in the .NET runtime to get the best of both worlds. In our design, programmers can choose between allocating objects in the garbage collected heap or the manual heap. All existing applications run unmodified, and without any performance degradation, using the garbage collected heap. Our programming model for manual memory management is flexible: although objects in the manual heap can have a single owning pointer, we allow deallocation at any program point and concurrent sharing of these objects amongst all the threads in the program. Experimental results from our .NET CoreCLR implementation on real-world applications show substantial performance gains especially in multithreaded scenarios: up to 3x savings in peak working sets and 2x improvements in runtime. 1 Introduction The importance of garbage collection (GC) in modern software cannot be overstated. GC greatly improves programmer productivity because it frees programmers from the burden of thinking about object lifetimes and freeing memory. Even more importantly, GC prevents temporal memory safety errors, i.e., uses of memory after it has been freed, which often lead to security breaches. Modern generational collectors, such as the .NET GC, deliver great throughput through a combination of fast thread-local bump allocation and cheap collection of young objects [63, 18, 61].
    [Show full text]
  • Ensuring the Spatial and Temporal Memory Safety of C at Runtime
    MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime Matthew S. Simpson, Rajeev K. Barua Department of Electrical & Computer Engineering University of Maryland, College Park College Park, MD 20742-3256, USA fsimpsom, [email protected] Abstract—Memory access violations are a leading source of dereferencing pointers obtained from invalid pointer arith- unreliability in C programs. As evidence of this problem, a vari- metic; and dereferencing uninitialized, NULL or “manufac- ety of methods exist that retrofit C with software checks to detect tured” pointers.1 A temporal error is a violation caused by memory errors at runtime. However, these methods generally suffer from one or more drawbacks including the inability to using a pointer whose referent has been deallocated (e.g. with detect all errors, the use of incompatible metadata, the need for free) and is no longer a valid object. The most well-known manual code modifications, and high runtime overheads. temporal violations include dereferencing “dangling” point- In this paper, we present a compiler analysis and transforma- ers to dynamically allocated memory and freeing a pointer tion for ensuring the memory safety of C called MemSafe. Mem- more than once. Dereferencing pointers to automatically allo- Safe makes several novel contributions that improve upon previ- ous work and lower the cost of safety. These include (1) a method cated memory (stack variables) is also a concern if the address for modeling temporal errors as spatial errors, (2) a compati- of the referent “escapes” and is made available outside the ble metadata representation combining features of object- and function in which it was defined.
    [Show full text]
  • Memory Tagging and How It Improves C/C++ Memory Safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018
    Memory Tagging and how it improves C/C++ memory safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018 Introduction 2 Memory Safety in C/C++ 2 AddressSanitizer 2 Memory Tagging 3 SPARC ADI 4 AArch64 HWASAN 4 Compiler And Run-time Support 5 Overhead 5 RAM 5 CPU 6 Code Size 8 Usage Modes 8 Testing 9 Always-on Bug Detection In Production 9 Sampling In Production 10 Security Hardening 11 Strengths 11 Weaknesses 12 Legacy Code 12 Kernel 12 Uninitialized Memory 13 Possible Improvements 13 Precision Of Buffer Overflow Detection 13 Probability Of Bug Detection 14 Conclusion 14 Introduction Memory safety in C and C++ remains largely unresolved. A technique usually called “memory tagging” may dramatically improve the situation if implemented in hardware with reasonable overhead. This paper describes two existing implementations of memory tagging: one is the full hardware implementation in SPARC; the other is a partially hardware-assisted compiler-based tool for AArch64. We describe the basic idea, evaluate the two implementations, and explain how they improve memory safety. This paper is intended to initiate a wider discussion of memory tagging and to motivate the CPU and OS vendors to add support for it in the near future. Memory Safety in C/C++ C and C++ are well known for their performance and flexibility, but perhaps even more for their extreme memory unsafety. This year we are celebrating the 30th anniversary of the Morris Worm, one of the first known exploitations of a memory safety bug, and the problem is still not solved.
    [Show full text]
  • Memory Management with Explicit Regions by David Edward Gay
    Memory Management with Explicit Regions by David Edward Gay Engineering Diploma (Ecole Polytechnique F´ed´erale de Lausanne, Switzerland) 1992 M.S. (University of California, Berkeley) 1997 A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the GRADUATE DIVISION of the UNIVERSITY of CALIFORNIA at BERKELEY Committee in charge: Professor Alex Aiken, Chair Professor Susan L. Graham Professor Gregory L. Fenves Fall 2001 The dissertation of David Edward Gay is approved: Chair Date Date Date University of California at Berkeley Fall 2001 Memory Management with Explicit Regions Copyright 2001 by David Edward Gay 1 Abstract Memory Management with Explicit Regions by David Edward Gay Doctor of Philosophy in Computer Science University of California at Berkeley Professor Alex Aiken, Chair Region-based memory management systems structure memory by grouping objects in regions under program control. Memory is reclaimed by deleting regions, freeing all objects stored therein. Our compiler for C with regions, RC, prevents unsafe region deletions by keeping a count of references to each region. RC's regions have advantages over explicit allocation and deallocation (safety) and traditional garbage collection (better control over memory), and its performance is competitive with both|from 6% slower to 55% faster on a collection of realistic benchmarks. Experience with these benchmarks suggests that modifying many existing programs to use regions is not difficult. An important innovation in RC is the use of type annotations that make the structure of a program's regions more explicit. These annotations also help reduce the overhead of reference counting from a maximum of 25% to a maximum of 12.6% on our benchmarks.
    [Show full text]
  • In This Issue
    FALL 2019 IN THIS ISSUE JONATHAN BISS CELEBRATING BEETHOVEN: PART I November 5 DANISH STRING QUARTET November 7 PILOBOLUS COME TO YOUR SENSES November 14–16 GABRIEL KAHANE November 23 MFA IN Fall 2019 | Volume 16, No. 2 ARTS LEADERSHIP FEATURE In This Issue Feature 3 ‘Indecent,’ or What it Means to Create Queer Jewish Theatre in Seattle Dialogue 9 Meet the Host of Tiny Tots Concert Series 13 We’re Celebrating 50 Years Empowering a new wave of Arts, Culture and Community of socially responsible Intermission Brain arts professionals Transmission 12 Test yourself with our Online and in-person trivia quiz! information sessions Upcoming Events seattleu.edu/artsleaderhip/graduate 15 Fall 2019 PAUL HEPPNER President Encore Stages is an Encore arts MIKE HATHAWAY Senior Vice President program that features stories Encore Ad 8-27-19.indd 1 8/27/19 1:42 PM KAJSA PUCKETT Vice President, about our local arts community Sales & Marketing alongside information about GENAY GENEREUX Accounting & performances. Encore Stages is Office Manager a publication of Encore Media Production Group. We also publish specialty SUSAN PETERSON Vice President, Production publications, including the SIFF JENNIFER SUGDEN Assistant Production Guide and Catalog, Official Seattle Manager ANA ALVIRA, STEVIE VANBRONKHORST Pride Guide, and the Seafair Production Artists and Graphic Designers Commemorative Magazine. Learn more at encorespotlight.com. Sales MARILYN KALLINS, TERRI REED Encore Stages features the San Francisco/Bay Area Account Executives BRIEANNA HANSEN, AMELIA HEPPNER, following organizations: ANN MANNING Seattle Area Account Executives CAROL YIP Sales Coordinator Marketing SHAUN SWICK Senior Designer & Digital Lead CIARA CAYA Marketing Coordinator Encore Media Group 425 North 85th Street • Seattle, WA 98103 800.308.2898 • 206.443.0445 [email protected] encoremediagroup.com Encore Arts Programs and Encore Stages are published monthly by Encore Media Group to serve musical and theatrical events in the Puget Sound and San Francisco Bay Areas.
    [Show full text]
  • Automated and Modular Refinement Reasoning for Concurrent Programs
    Automated and modular refinement reasoning for concurrent programs Chris Hawblitzel Erez Petrank Shaz Qadeer Serdar Tasiran Microsoft Technion Microsoft Ko¸cUniversity Abstract notable successes using the refinement approach in- clude the work of Abrial et al. [2] and the proof of full We present civl, a language and verifier for concur- functional correctness of the seL4 microkernel [37]. rent programs based on automated and modular re- This paper presents the first general and automated finement reasoning. civl supports reasoning about proof system for refinement verification of shared- a concurrent program at many levels of abstraction. memory multithreaded software. Atomic actions in a high-level description are refined We present our verification approach in the context to fine-grain and optimized lower-level implementa- of civl, an idealized concurrent programming lan- tions. A novel combination of automata theoretic guage. In civl, a program is described as a collection and logic-based checks is used to verify refinement. of procedures whose implementation can use the stan- Modular specifications and proof annotations, such dard features such as assignment, conditionals, loops, as location invariants and procedure pre- and post- procedure calls, and thread creation. Each procedure conditions, are specified separately, independently at accesses shared global variables only through invoca- each level in terms of the variables visible at that tions of atomic actions. A subset of the atomic ac- level. We have implemented as an extension to civl tions may be refined by new procedures and a new the language and verifier. We have used boogie civl program is obtained by replacing the invocation of an to refine a realistic concurrent garbage collection al- atomic action by a call to the corresponding proce- gorithm from a simple high-level specification down dure refining the action.
    [Show full text]
  • An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K
    An Evolutionary Study of Linux Memory Management for Fun and Profit Jian Huang, Moinuddin K. Qureshi, and Karsten Schwan, Georgia Institute of Technology https://www.usenix.org/conference/atc16/technical-sessions/presentation/huang This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0 Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. An Evolutionary Study of inu emory anagement for Fun and rofit Jian Huang, Moinuddin K. ureshi, Karsten Schwan Georgia Institute of Technology Astract the patches committed over the last five years from 2009 to 2015. The study covers 4587 patches across Linux We present a comprehensive and uantitative study on versions from 2.6.32.1 to 4.0-rc4. We manually label the development of the Linux memory manager. The each patch after carefully checking the patch, its descrip- study examines 4587 committed patches over the last tions, and follow-up discussions posted by developers. five years (2009-2015) since Linux version 2.6.32. In- To further understand patch distribution over memory se- sights derived from this study concern the development mantics, we build a tool called MChecker to identify the process of the virtual memory system, including its patch changes to the key functions in mm. MChecker matches distribution and patterns, and techniues for memory op- the patches with the source code to track the hot func- timizations and semantics. Specifically, we find that tions that have been updated intensively.
    [Show full text]
  • Proceedings, the 57Th Annual Meeting, 1981
    PROCEEDINGS THE FIFTY-SEVENTH ANNUAL MEETING National Association of Schools of Music NUMBER 70 APRIL 1982 NATIONAL ASSOCIATION OF SCHOOLS OF MUSIC PROCEEDINGS OF THE 57th ANNUAL MEETING Dallas, Texas I98I COPYRIGHT © 1982 ISSN 0190-6615 NATIONAL ASSOCIATION OF SCHOOLS OF MUSIC 11250 ROGER BACON DRIVE, NO. 5, RESTON, VA. 22090 All rights reserved including the right to reproduce this book or parts thereof in any form. CONTENTS Speeches Presented Music, Education, and Music Education Samuel Lipman 1 The Preparation of Professional Musicians—Articulation between Elementary/Secondary and Postsecondary Training: The Role of Competitions Robert Freeman 11 Issues in the Articulation between Elementary/Secondary and Postsecondary Training Kenneth Wendrich 19 Trends and Projections in Music Teacher Placement Charles Lutton 23 Mechanisms for Assisting Young Professionals to Organize Their Approach to the Job Market: What Techniques Should Be Imparted to Graduating Students? Brandon Mehrle 27 The Academy and the Marketplace: Cooperation or Conflict? Joseph W.Polisi 30 "Apples and Oranges:" Office Applications of the Micro Computer." Lowell M. Creitz 34 Microcomputers and Music Learning: The Development of the Illinois State University - Fine Arts Instruction Center, 1977-1981. David L. Shrader and David B. Williams 40 Reaganomics and Arts Legislation Donald Harris 48 Reaganomics and Art Education: Realities, Implications, and Strategies for Survival Frank Tirro 52 Creative Use of Institutional Resources: Summer Programs, Interim Programs, Preparatory Divisions, Radio and Television Programs, and Recordings Ray Robinson 56 Performance Competitions: Relationships to Professional Training and Career Entry Eileen T. Cline 63 Teaching Aesthetics of Music Through Performance Group Experiences David M.Smith 78 An Array of Course Topics for Music in General Education Robert R.
    [Show full text]
  • Why Is Memory Safety Still a Concern?
    Why is memory safety still a concern? PhD Candidacy Exam Mohamed (Tarek Ibn Ziad) Hassan [email protected] Department of Computer Science Columbia University April 9th, 2020 10:30 A.M. Location: TBD 1 Candidate Research Area Statement Languages like C and C++ are the gold standard for implementing a wide range of software systems such as safety critical firmware, operating system kernels, and network protocol stacks for performance and flexibility reasons. As those languages do not guarantee the validity of memory accesses (i.e., enforce memory safety), seemingly benign program bugs can lead to silent memory corruption, difficult-to-diagnose crashes, and most importantly; security exploitation. Attackers can compromise the security of the whole computing ecosystem by exploiting a memory safety error with a suitably crafted input. Since the spread of Morris worm in 1988 and despite massive advances in memory safety error mitigations, memory safety errors have risen to be the most exploited vulnerabilities. As part of my research studies in Columbia, I have worked on designing and implementing hardware primitives [1,2] that provide fine-grained memory safety protection with low performance overheads com- pared to existing work. My ongoing work in this research include extending the above primitives to system level protection in addition to addressing their current limitations. 2 Faculty Committee Members The candidate respectfully solicits the guidance and expertise of the following faculty members and welcomes suggestions for other important papers and publications in the exam research area. • Prof. Simha Sethumadhavan • Prof. Steven M. Bellovin • Prof. Suman Jana 1 Why is memory safety still a concern? PhD Candidacy Exam 3 Exam Syllabus The papers have broad coverage in the space of memory safety vulnerabilities and mitigations, which are needed to (1) make a fair assessment of current defensive and offensive techniques and (2) explore new threats and defensive opportunities.
    [Show full text]
  • Diehard: Probabilistic Memory Safety for Unsafe Languages
    DieHard: Probabilistic Memory Safety for Unsafe Languages Emery D. Berger Benjamin G. Zorn Dept. of Computer Science Microsoft Research University of Massachusetts Amherst One Microsoft Way Amherst, MA 01003 Redmond, WA 98052 [email protected] [email protected] Abstract Invalid frees: Passing illegal addresses to free can corrupt the Applications written in unsafe languages like C and C++ are vul- heap or lead to undefined behavior. nerable to memory errors such as buffer overflows, dangling point- Double frees: Repeated calls to free of objects that have already ers, and reads of uninitialized data. Such errors can lead to program been freed undermine the integrity of freelist-based allocators. crashes, security vulnerabilities, and unpredictable behavior. We present DieHard, a runtime system that tolerates these errors while Tools like Purify [17] and Valgrind [28, 34] allow programmers to probabilistically maintaining soundness. DieHard uses randomiza- pinpoint the exact location of these memory errors (at the cost of a tion and replication to achieve probabilistic memory safety through 2-25X performance penalty), but only reveal those bugs found dur- the illusion of an infinite-sized heap. DieHard’s memory manager ing testing. Deployed programs thus remain vulnerable to crashes randomizes the location of objects in a heap that is at least twice or attack. Conservative garbage collectors can, at the cost of in- as large as required. This algorithm not only prevents heap corrup- creased runtime and additional memory [10, 20], disable calls to tion but also provides a probabilistic guarantee of avoiding memory free and so eliminate three of the above errors (invalid frees, dou- errors.
    [Show full text]
  • Simple, Fast and Safe Manual Memory Management
    Simple, Fast and Safe Manual Memory Management Piyus Kedia Manuel Costa Matthew Aaron Blankstein ∗ Microsoft Research, India Parkinson Kapil Vaswani Princeton University, USA [email protected] Dimitrios Vytiniotis [email protected] Microsoft Research, UK manuelc,mattpark,kapilv,[email protected] Abstract cause the latter are more efficient. As a consequence, many Safe programming languages are readily available, but many applications continue to have exploitable memory safety applications continue to be written in unsafe languages be- bugs. One of the main reasons behind the higher efficiency cause of efficiency. As a consequence, many applications of unsafe languages is that they typically use manual mem- continue to have exploitable memory safety bugs. Since ory management, which has been shown to be more efficient garbage collection is a major source of inefficiency in the than garbage collection [19, 21, 24, 33, 34, 45]. Thus, replac- implementation of safe languages, replacing it with safe ing garbage collection with manual memory management in manual memory management would be an important step safe languages would be an important step towards solv- towards solving this problem. ing this problem. The challenge is how to implement man- Previous approaches to safe manual memory manage- ual memory management efficiently, without compromising ment use programming models based on regions, unique safety. pointers, borrowing of references, and ownership types. We Previous approaches to safe manual memory manage- propose a much simpler programming model that does not ment use programming models based on regions [20, 40], require any of these concepts. Starting from the design of an unique pointers [22, 38], borrowing of references [11, 12, imperative type safe language (like Java or C#), we just add 42], and ownership types [10, 12, 13].
    [Show full text]