Combining Garbage Collection and Safe Manual Memory Management
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Memory Management and Garbage Collection
Overview Memory Management Stack: Data on stack (local variables on activation records) have lifetime that coincides with the life of a procedure call. Memory for stack data is allocated on entry to procedures ::: ::: and de-allocated on return. Heap: Data on heap have lifetimes that may differ from the life of a procedure call. Memory for heap data is allocated on demand (e.g. malloc, new, etc.) ::: ::: and released Manually: e.g. using free Automatically: e.g. using a garbage collector Compilers Memory Management CSE 304/504 1 / 16 Overview Memory Allocation Heap memory is divided into free and used. Free memory is kept in a data structure, usually a free list. When a new chunk of memory is needed, a chunk from the free list is returned (after marking it as used). When a chunk of memory is freed, it is added to the free list (after marking it as free) Compilers Memory Management CSE 304/504 2 / 16 Overview Fragmentation Free space is said to be fragmented when free chunks are not contiguous. Fragmentation is reduced by: Maintaining different-sized free lists (e.g. free 8-byte cells, free 16-byte cells etc.) and allocating out of the appropriate list. If a small chunk is not available (e.g. no free 8-byte cells), grab a larger chunk (say, a 32-byte chunk), subdivide it (into 4 smaller chunks) and allocate. When a small chunk is freed, check if it can be merged with adjacent areas to make a larger chunk. Compilers Memory Management CSE 304/504 3 / 16 Overview Manual Memory Management Programmer has full control over memory ::: with the responsibility to manage it well Premature free's lead to dangling references Overly conservative free's lead to memory leaks With manual free's it is virtually impossible to ensure that a program is correct and secure. -
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]. -
Memory Safety Without Garbage Collection for Embedded Applications
Memory Safety Without Garbage Collection for Embedded Applications DINAKAR DHURJATI, SUMANT KOWSHIK, VIKRAM ADVE, and CHRIS LATTNER University of Illinois at Urbana-Champaign Traditional approaches to enforcing memory safety of programs rely heavily on run-time checks of memory accesses and on garbage collection, both of which are unattractive for embedded ap- plications. The goal of our work is to develop advanced compiler techniques for enforcing memory safety with minimal run-time overheads. In this paper, we describe a set of compiler techniques that, together with minor semantic restrictions on C programs and no new syntax, ensure memory safety and provide most of the error-detection capabilities of type-safe languages, without using garbage collection, and with no run-time software checks, (on systems with standard hardware support for memory management). The language permits arbitrary pointer-based data structures, explicit deallocation of dynamically allocated memory, and restricted array operations. One of the key results of this paper is a compiler technique that ensures that dereferencing dangling pointers to freed memory does not violate memory safety, without annotations, run-time checks, or garbage collection, and works for arbitrary type-safe C programs. Furthermore, we present a new inter- procedural analysis for static array bounds checking under certain assumptions. For a diverse set of embedded C programs, we show that we are able to ensure memory safety of pointer and dy- namic memory usage in all these programs with no run-time software checks (on systems with standard hardware memory protection), requiring only minor restructuring to conform to simple type restrictions. Static array bounds checking fails for roughly half the programs we study due to complex array references, and these are the only cases where explicit run-time software checks would be needed under our language and system assumptions. -
Memory Leak Or Dangling Pointer
Modern C++ for Computer Vision and Image Processing Igor Bogoslavskyi Outline Using pointers Pointers are polymorphic Pointer “this” Using const with pointers Stack and Heap Memory leaks and dangling pointers Memory leak Dangling pointer RAII 2 Using pointers in real world Using pointers for classes Pointers can point to objects of custom classes: 1 std::vector<int> vector_int; 2 std::vector<int >* vec_ptr = &vector_int; 3 MyClass obj; 4 MyClass* obj_ptr = &obj; Call object functions from pointer with -> 1 MyClass obj; 2 obj.MyFunc(); 3 MyClass* obj_ptr = &obj; 4 obj_ptr->MyFunc(); obj->Func() (*obj).Func() ↔ 4 Pointers are polymorphic Pointers are just like references, but have additional useful properties: Can be reassigned Can point to ‘‘nothing’’ (nullptr) Can be stored in a vector or an array Use pointers for polymorphism 1 Derived derived; 2 Base* ptr = &derived; Example: for implementing strategy store a pointer to the strategy interface and initialize it with nullptr and check if it is set before calling its methods 5 1 #include <iostream > 2 #include <vector > 3 using std::cout; 4 struct AbstractShape { 5 virtual void Print() const = 0; 6 }; 7 struct Square : public AbstractShape { 8 void Print() const override { cout << "Square\n";} 9 }; 10 struct Triangle : public AbstractShape { 11 void Print() const override { cout << "Triangle\n";} 12 }; 13 int main() { 14 std::vector<AbstractShape*> shapes; 15 Square square; 16 Triangle triangle; 17 shapes.push_back(&square); 18 shapes.push_back(&triangle); 19 for (const auto* shape : shapes) { shape->Print(); } 20 return 0; 21 } 6 this pointer Every object of a class or a struct holds a pointer to itself This pointer is called this Allows the objects to: Return a reference to themselves: return *this; Create copies of themselves within a function Explicitly show that a member belongs to the current object: this->x(); 7 Using const with pointers Pointers can point to a const variable: 1 // Cannot change value , can reassign pointer. -
Transparent Garbage Collection for C++
Document Number: WG21/N1833=05-0093 Date: 2005-06-24 Reply to: Hans-J. Boehm [email protected] 1501 Page Mill Rd., MS 1138 Palo Alto CA 94304 USA Transparent Garbage Collection for C++ Hans Boehm Michael Spertus Abstract A number of possible approaches to automatic memory management in C++ have been considered over the years. Here we propose the re- consideration of an approach that relies on partially conservative garbage collection. Its principal advantage is that objects referenced by ordinary pointers may be garbage-collected. Unlike other approaches, this makes it possible to garbage-collect ob- jects allocated and manipulated by most legacy libraries. This makes it much easier to convert existing code to a garbage-collected environment. It also means that it can be used, for example, to “repair” legacy code with deficient memory management. The approach taken here is similar to that taken by Bjarne Strous- trup’s much earlier proposal (N0932=96-0114). Based on prior discussion on the core reflector, this version does insist that implementations make an attempt at garbage collection if so requested by the application. How- ever, since there is no real notion of space usage in the standard, there is no way to make this a substantive requirement. An implementation that “garbage collects” by deallocating all collectable memory at process exit will remain conforming, though it is likely to be unsatisfactory for some uses. 1 Introduction A number of different mechanisms for adding automatic memory reclamation (garbage collection) to C++ have been considered: 1. Smart-pointer-based approaches which recycle objects no longer ref- erenced via special library-defined replacement pointer types. -
Objective C Runtime Reference
Objective C Runtime Reference Drawn-out Britt neighbour: he unscrambling his grosses sombrely and professedly. Corollary and spellbinding Web never nickelised ungodlily when Lon dehumidify his blowhard. Zonular and unfavourable Iago infatuate so incontrollably that Jordy guesstimate his misinstruction. Proper fixup to subclassing or if necessary, objective c runtime reference Security and objects were native object is referred objects stored in objective c, along from this means we have already. Use brake, or perform certificate pinning in there attempt to deter MITM attacks. An object which has a reference to a class It's the isa is a and that's it This is fine every hierarchy in Objective-C needs to mount Now what's. Use direct access control the man page. This function allows us to voluntary a reference on every self object. The exception handling code uses a header file implementing the generic parts of the Itanium EH ABI. If the method is almost in the cache, thanks to Medium Members. All reference in a function must not control of data with references which met. Understanding the Objective-C Runtime Logo Table Of Contents. Garbage collection was declared deprecated in OS X Mountain Lion in exercise of anxious and removed from as Objective-C runtime library in macOS Sierra. Objective-C Runtime Reference. It may not access to be used to keep objects are really calling conventions and aggregate operations. Thank has for putting so in effort than your posts. This will cut down on the alien of Objective C runtime information. Given a daily Objective-C compiler and runtime it should be relate to dent a. -
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. -
Programming Language Concepts Memory Management in Different
Programming Language Concepts Memory management in different languages Janyl Jumadinova 13 April, 2017 I Use external software, such as the Boehm-Demers-Weiser collector (a.k.a. Boehm GC), to do garbage collection in C/C++: { use Boehm instead of traditional malloc and free in C http://hboehm.info/gc/ C I Memory management is typically manual: { the standard library functions for memory management in C, malloc and free, have become almost synonymous with manual memory management. 2/16 C I Memory management is typically manual: { the standard library functions for memory management in C, malloc and free, have become almost synonymous with manual memory management. I Use external software, such as the Boehm-Demers-Weiser collector (a.k.a. Boehm GC), to do garbage collection in C/C++: { use Boehm instead of traditional malloc and free in C http://hboehm.info/gc/ 2/16 I In addition to Boehm, we can use smart pointers as a memory management solution. C++ I The standard library functions for memory management in C++ are new and delete. I The higher abstraction level of C++ makes the bookkeeping required for manual memory management even harder than C. 3/16 C++ I The standard library functions for memory management in C++ are new and delete. I The higher abstraction level of C++ makes the bookkeeping required for manual memory management even harder than C. I In addition to Boehm, we can use smart pointers as a memory management solution. 3/16 Smart pointer: // declare a smart pointer on stack // and pass it the raw pointer SomeSmartPtr<MyObject> ptr(new MyObject()); ptr->DoSomething(); // use the object in some way // destruction of the object happens automatically C++ Raw pointer: MyClass *ptr = new MyClass(); ptr->doSomething(); delete ptr; // destroy the object. -
Memory Management Algorithms and Implementation in C/C++
Memory Management Algorithms and Implementation in C/C++ by Bill Blunden Wordware Publishing, Inc. Library of Congress Cataloging-in-Publication Data Blunden, Bill, 1969- Memory management: algorithms and implementation in C/C++ / by Bill Blunden. p. cm. Includes bibliographical references and index. ISBN 1-55622-347-1 1. Memory management (Computer science) 2. Computer algorithms. 3. C (Computer program language) 4. C++ (Computer program language) I. Title. QA76.9.M45 .B558 2002 005.4'35--dc21 2002012447 CIP © 2003, Wordware Publishing, Inc. All Rights Reserved 2320 Los Rios Boulevard Plano, Texas 75074 No part of this book may be reproduced in any form or by any means without permission in writing from Wordware Publishing, Inc. Printed in the United States of America ISBN 1-55622-347-1 10987654321 0208 Product names mentioned are used for identification purposes only and may be trademarks of their respective companies. All inquiries for volume purchases of this book should be addressed to Wordware Publishing, Inc., at the above address. Telephone inquiries may be made by calling: (972) 423-0090 This book is dedicated to Rob, Julie, and Theo. And also to David M. Lee “I came to learn physics, and I got Jimmy Stewart” iii Table of Contents Acknowledgments......................xi Introduction.........................xiii Chapter 1 Memory Management Mechanisms. 1 MechanismVersusPolicy..................1 MemoryHierarchy......................3 AddressLinesandBuses...................9 Intel Pentium Architecture . 11 RealModeOperation...................14 Protected Mode Operation. 18 Protected Mode Segmentation . 19 ProtectedModePaging................26 PagingasProtection..................31 Addresses: Logical, Linear, and Physical . 33 PageFramesandPages................34 Case Study: Switching to Protected Mode . 35 ClosingThoughts......................42 References..........................43 Chapter 2 Memory Management Policies. -
Object Oriented Programming in Objective-C 2501ICT/7421ICT Nathan
Subclasses, Access Control, and Class Methods Advanced Topics Object Oriented Programming in Objective-C 2501ICT/7421ICT Nathan René Hexel School of Information and Communication Technology Griffith University Semester 1, 2012 René Hexel Object Oriented Programming in Objective-C Subclasses, Access Control, and Class Methods Advanced Topics Outline 1 Subclasses, Access Control, and Class Methods Subclasses and Access Control Class Methods 2 Advanced Topics Memory Management Strings René Hexel Object Oriented Programming in Objective-C Subclasses, Access Control, and Class Methods Subclasses and Access Control Advanced Topics Class Methods Objective-C Subclasses Objective-C Subclasses René Hexel Object Oriented Programming in Objective-C Subclasses, Access Control, and Class Methods Subclasses and Access Control Advanced Topics Class Methods Subclasses in Objective-C Classes can extend other classes @interface AClass: NSObject every class should extend at least NSObject, the root class to subclass a different class, replace NSObject with the class you want to extend self references the current object super references the parent class for method invocations René Hexel Object Oriented Programming in Objective-C Subclasses, Access Control, and Class Methods Subclasses and Access Control Advanced Topics Class Methods Creating Subclasses: Point3D Parent Class: Point.h Child Class: Point3D.h #import <Foundation/Foundation.h> #import "Point.h" @interface Point: NSObject @interface Point3D: Point { { int x; // member variables int z; // add z dimension -
Basic Garbage Collection Garbage Collection (GC) Is the Automatic
Basic Garbage Collection Garbage Collection (GC) is the automatic reclamation of heap records that will never again be accessed by the program. GC is universally used for languages with closures and complex data structures that are implicitly heap-allocated. GC may be useful for any language that supports heap allocation, because it obviates the need for explicit deallocation, which is tedious, error-prone, and often non- modular. GC technology is increasingly interesting for “conventional” language implementation, especially as users discover that free isn’t free. i.e., explicit memory management can be costly too. We view GC as part of an allocation service provided by the runtime environment to the user program, usually called the mutator( user program). When the mutator needs heap space, it calls an allocation routine, which in turn performs garbage collection activities if needed. Many high-level programming languages remove the burden of manual memory management from the programmer by offering automatic garbage collection, which deallocates unreachable data. Garbage collection dates back to the initial implementation of Lisp in 1958. Other significant languages that offer garbage collection include Java, Perl, ML, Modula-3, Prolog, and Smalltalk. Principles The basic principles of garbage collection are: 1. Find data objects in a program that cannot be accessed in the future 2. Reclaim the resources used by those objects Many computer languages require garbage collection, either as part of the language specification (e.g., Java, C#, and most scripting languages) or effectively for practical implementation (e.g., formal languages like lambda calculus); these are said to be garbage collected languages. -
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.