DOCSLIB.ORG

Region-Based Memory Management

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Region-Based Memory Management Region-based Memory Management Advanced Operating Systems Lecture 10 Lecture Outline • Rationale • Stack-based memory management • Region-based memory management • Ownership • Borrowing • Benefits and limitations 2 Rationale • Garbage collection tends to have unpredictable timing and high memory overhead • Real-time collectors exist, but are uncommon and have significant design implications for applications using them • Manual memory management is too error prone • Region-based memory management aims for a middle ground between the two approaches • Safe, predictable timing • Limited impact on application design 3 Stack-based Memory Management • Automatic allocation/deallocation of variables on the stack is common and efficient: #include <math.h> #include <stdio.h> #include <stdlib.h> static double pi = 3.14159; Global variables static double conic_area(double w, double h) { double pi = 3.14159 double r = w / 2.0; double a = pi * r * (r + sqrt(h*h + r*r)); Stack frame for main() return a; double width = … } double height = … double area = … int main() { double width = 3; Stack frame for conic_area() double height = 2; double area = conic_area(width, height); double w = … double h = … double r = … printf("area of cone = %f\n", area); double a = … return 0; } 4 Stack-based Memory Management • Hierarchy of regions corresponding to call stack: • Global variables • Local variables in each function • Lexically scoped variables within functions double vector_avg(double *vec, int len) { double sum = 0; Lifetime of sum – local variable in function for (int i = 0; i < len; i++) { Lifetime of i – lexically scoped sum += vec[i]; } return sum / len; } • Variables live within regions, and are deallocated at end of region scope 5 Stack-based Memory Management • Limitation: requires data to be allocated on stack • Example: int hostname_matches(char *requested, char *host, char *domain) { char *tmp = malloc(strlen(host) + strlen(domain) + 2); sprintf(tmp, “%s.%s”, host, domain); if (strcmp(requested, host) == 0) { return 1; } if (strcmp(requested, tmp) == 0) { return 1; } return 0; } The local variable tmp (pointer of type char *) is freed when the function returns; the allocated memory is not freed • Heap storage has to be managed manually 6 Region-based Memory Allocation • Stack allocation effective within a narrow domain – can we extend the ideas to manage the heap? • Create pointers to heap allocated memory • Pointers are stored on the stack and have lifetime matching the stack frame – pointers have type Box<T> for a pointer to heap allocated T • The heap allocation has lifetime matching that of the Box – when the Box goes out of scope, the heap memory it references is freed • i.e., the destructor of the Box<T> frees the heap allocated T • Efficient, but loses generality of heap allocation since ties heap allocation to stack frames 7 Region-based Memory Management • For effective region-based memory management: • Allocate objects with lifetimes corresponding to regions • Track object ownership, and changes of ownership: • What region owns each object at any time • Ownership of objects can move between regions • Deallocate objects at the end of the lifetime of their owning region • Use scoping rules to ensure objects are not referenced after deallocation • Example: the Rust programming language • Builds on previous research with Cyclone language (AT&T/Cornell) • Somewhat similar ideas in Microsoft’s Singularity operating system 8 Returning Ownership of Data • Returning data from a function causes it to outlive the region in which it was created: Lifetime of local variables const PI: f64 = 3.14159; in area_of_cone fn area_of_cone(w : f64, h : f64) -> f64 { let r = w / 2.0; let a = PI * r * (r + (h*h + r*r).sqrt()); return a; } fn main() { let width = 3.0; Lifetime of a let height = 2.0; let area = area_of_cone(width, height); println!("area = {}", area); } 9 Returning Ownership of Data • Runtime must track changes in ownership as data is returned • Copies made of stack-allocated local variables; original deallocated, copy has lifetime of stack-allocated local variable in calling function • Allows us to return a copy of a Box<T> that references a heap allocated value of type T • Effective with a reference counting implementation • Creating the new Box<T> temporarily increases the reference count on the heap-allocated T • The original box is then immediately deallocated, reducing the reference count again • (An optimised runtime can eliminate the changes to the reference count) • The heap-allocated T is deallocated when the box goes out of scope of the outer region • Allows data to be passed around, if it always has a single owner 10 Giving Ownership of Data % cat consume.rs • Ownership of parameters passed fn consume(mut x : Vec<u32>) { to a function is transferred to that x.push(1); function } Lifetime of a • Deallocated when function ends, unless it fn main() { returns the data let mut a = Vec::new(); • Data cannot be later used by the calling function – enforced at compile time a.push(1); a.push(2); Ownership of a transferred to consume() consume(a); println!("a.len() = {}", a.len()); } % rustc consume.rs consume.rs:15:28: 15:29 error: use of moved value: `a` [E0382] consume.rs:15 println!("a.len() = {}", a.len()); ^ 11 Borrowing Data % cat borrow.rs • Functions can borrow references to fn borrow(mut x : &mut Vec<u32>) { data owned by an enclosing scope x.push(1); } • Does not transfer ownership of the data A mutable reference • Naïvely safe to use, since live longer than fn main() { the function let mut a = &mut Vec::new(); a.push(1); a.push(2); • Can also return references to input parameters passed as references borrow(a); • Safe, since these references must live longer println!("a.len() = {}", a.len()); than the function } % rustc borrow.rs % ./borrow a.len() = 3 % 12 Problems with Naïve Borrowing % cat borrow.rs • The borrow() function changes fn borrow(mut x : &mut Vec<u32>) { the contents of the vector x.push(1); } • But – it cannot know whether it is fn main() { safe to do so let mut a = &mut Vec::new(); • In this example, it is safe If was iterating over the contents of a.push(1); • main() the vector, changing the contents might lead a.push(2); to elements being skipped or duplicated, or to a result to be calculated with inconsistent borrow(a); data println!("a.len() = {}", a.len()); • Known as iterator invalidation } % rustc borrow.rs % ./borrow a.len() = 3 % 13 Safe Borrowing • Rust has two kinds of pointer: • To change an object: • &T – a shared reference to an immutable • You either own the object, and it is not object of type T marked as immutable; or • &mut T – a unique reference to a mutable • You have the only &mut reference to it object of type T • Runtime system controls pointer • Prevents iterator invalidation ownership and use • The iterator requires an &T reference, so • An object of type T can be referenced by other code can’t get a mutable reference one or more references of type &T, or by to the contents to change them: exactly 1 reference of type &mut T, but fn main() { not both let mut data = vec![1, 2, 3, 4, 5, 6]; for x in &data { fails, since push takes Cannot get an reference to data data.push(2 * x); • &mut T an &mut reference of type T that is marked as immutable } } • Allows functions to safely borrow enforced at compile time objects – without needing to give away ownership 14 Benefits • Type system tracks ownership, turning run-time bugs into compile-time errors: • Prevents memory leaks and use-after-free bugs • Prevents iterator invalidation • Prevents race conditions with multiple threads – borrowing rules prevent two threads from getting references to a mutable object • Efficient run-time behaviour – timing and memory usage are predictable 15 Limitations of Region-based Systems • Can’t express cyclic data structures • E.g., can’t build a doubly linked list: Can’t get mutable reference a b c d to c to add the link to d, since already referenced by b • Many languages offer an escape hatch from the ownership rules to allow these data structures (e.g., raw pointers and unsafe in Rust) • Can’t express shared ownership of mutable data • Usually a good thing, since avoids race conditions • Rust has RefCell<T> that dynamically enforces the borrowing rules (i.e., allows upgrading a shared reference to an immutable object into a unique reference to a mutable object, if it was the only such shared reference) • Raises a run-time exception if there could be a race condition, rather than preventing it at compile time 16 Limitations of Region-based Systems • Forces programmer to consider object ownership early and explicitly • Generally good practice, but increases conceptual load early in design process – may hinder exploratory programming 17 Summary • Region-based memory management with strong Region-Based Memory Management in Cyclone ∗ Dan Grossman Greg Morrisett Trevor Jim† ownership and borrowing rules Michael Hicks Yanling Wang James Cheney Computer Science Department †AT&T Labs Research Cornell University 180 Park Avenue Ithaca, NY 14853 Florham Park, NJ 07932 danieljg,jgm,mhicks,wangyl,jcheney @cs.cornell.edu [email protected] • Efficient and predictable behaviour { } ABSTRACT control over data representation (e.g., field layout) and re- Cyclone is a type-safe programming language derived from source management (e.g., memory management). The de C. The primary design goal of Cyclone is to let program- facto language for coding such systems is C. However, in Strong correctness guarantees prevent many common bugs mers control data representation and memory management providing low-level control, C admits a wide class of danger- • without sacrificing type-safety. In this paper, we focus on ous — and extremely common — safety violations, such as the region-based memory management of Cyclone and its incorrect type casts, buffer overruns, dangling-pointer deref- static typing discipline.
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.
    [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]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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
    [Show full text]
  • 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.
    [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]
  • Memscope: Analyzing Memory Duplication on Android Systems
    MemScope: Analyzing Memory Duplication on Android Systems Byeoksan Lee, Seong Min Kim, Eru Park, Dongsu Han KAIST Abstract tion (e.g., log-in) when the app is reloaded. Additionally, it leads to longer reload time [15]. Main memory is one of the most important and valuable As users run an increasing number of applications and resources in mobile devices. While resource efficiency, in each application becomes more complex, the memory pres- general, is important in mobile computing where programs sure on mobile devices is increasing. This coupled with the run on limited battery power and resources, managing main rise of low memory devices [5] makes the problem even memory is especially critical because it has a significant more important. Android itself tried to reduce system mem- impact on user experience. However, there is mounting ory footprint and produced a way to tune the system for low evidence that Android systems do not utilize main memory memory devices [6]. However, there is mounting evidence efficiently, and actually cause page-level duplications in the that Android systems do not utilize main memory efficiently, physical memory. This paper takes the first step in accurately and actually cause page-level duplications in the physical measuring the level of memory duplication and diagnosing memory [5, 13]. the root cause of the problem. To this end, we develop a To mitigate the problem, Android has introduced several system called MemScope that automatically identifies and mechanisms to optimize the system for low memory de- measures memory duplication levels for Android systems. It vices, such as Kernel Same-page Merging (KSM) [8] and identifies which memory segment contains duplicate memory zRAM [12].
    [Show full text]
  • Optimization Techniques for Memory Virtualization-Based Resource Management
    SSStttooonnnyyy BBBrrrooooookkk UUUnnniiivvveeerrrsssiiitttyyy The official electronic file of this thesis or dissertation is maintained by the University Libraries on behalf of The Graduate School at Stony Brook University. ©©© AAAllllll RRRiiiggghhhtttsss RRReeessseeerrrvvveeeddd bbbyyy AAAuuuttthhhooorrr... Optimization Techniques for Memory Virtualization-based Resource Management A Dissertation Presented by Jui-Hao Chiang to The Graduate School in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science Stony Brook University December 2012 Stony Brook University The Graduate School Jui-Hao Chiang We, the dissertation committee for the above candidate for the Doctor of Philosophy degree, hereby recommend acceptance of this dissertation. Tzi-cker Chiueh { Dissertation Advisor Professor, Department of Computer Science Jie Gao { Chairperson of Defense Associate Professor, Department of Computer Science Rob Johnson Assistant Professor, Department of Computer Science Ted Teng Professor, Department of Technology and Society This dissertation is accepted by the Graduate School. Charles Taber Interim Dean of the Graduate School ii Abstract of the Dissertation Optimization Techniques for Memory Virtualization-based Resource Management by Jui-Hao Chiang Doctor of Philosophy in Computer Science Stony Brook University 2012 Memory virtualization abstracts the physical memory resources in a virtualized server in such a way that offers many resource man- agement advantages, such as consolidation, sharing,
    [Show full text]
  • Mostly Concurrent Garbage Collection
    Mostly Concurrent Garbage Collection Marco Ammon [email protected] Lehrstuhl für Informatik 4 Friedrich-Alexander-Universität Erlangen-Nürnberg Erlangen, Germany ABSTRACT For performing an accurate reachability analysis, program execu- Automated Garbage Collection (GC) is desired for many applications tion is usually halted during garbage collection, which is called a due to difficulties with manual memory management. Conventional stop-the-world (STW) approach. tracing garbage collectors require a complete halt of the program Consequently, as this process requires to scan large portions of while unreachable objects are detected and reclaimed. However, the the heap, application latency can significantly increase due to long resulting increased latency is not always tolerable. This paper gives pauses. In particular for interactive applications, web services, or an introduction into GC fundamentals before thoroughly explaining real-time constrained programs, this may not be tolerable [8, 13, 27]. and discussing the mostly concurrent mark-and-sweep algorithm Hence, alternatives to the STW method are often desired. presented in [8]. The approach is based on the principle of combin- In Section 2, different approaches to tracing garbage collectors ing a concurrent marking phase with a short stop-the-world pause are presented. Section 3 explains and discusses a particular algo- to process modifications which occurred simultaneously. Addition- rithm for mostly concurrent GC [8] proposed by Boehm et al., which ally, the influence of this concept on modern garbage collectors on combines a short stop-the-world phase with longer, concurrently the Java Virtual Machine is reviewed. executed marking operations. Given the historic significance, its in- fluence on some contemporary GC algorithms for the popular Java Virtual Machine (JVM) is reviewed in Section 4.
    [Show full text]