DOCSLIB.ORG

Sampling-Based Motion Planning Algorithms: Analysis and Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Sampling-Based Motion Planning Algorithms: Analysis and Development SAMPLING-BASED MOTION PLANNING ALGORITHMS: ANALYSIS AND DEVELOPMENT by NATHAN ALEXANDER WEDGE Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Dissertation Advisor: Dr. Michael S. Branicky Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY May, 2011 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the dissertation of Nathan Alexander Wedge candidate for the Doctor of Philosophy degree∗. Michael S. Branicky (committee chair) M. Cenk C¸avu¸so˘glu (committee member) Wyatt S. Newman (committee member) Soumya Ray (committee member) March 25, 2011 ∗We also certify that written approval has been obtained for any proprietary material contained herein. Table of Contents List of Tables v List of Figures vi List of Algorithms ix Acknowledgements x Abstract xii 1 Introduction 14 1.1 Motion Planning . 14 1.1.1 Problem Characterizations . 15 1.2 Experimental Problems . 18 1.3 Contributions and Outline . 19 2 Background 23 2.1 Combinatorial Planning . 23 2.2 Sampling-based Planning Methodology . 25 2.2.1 Sampling and Randomization . 26 2.2.2 Distance and Metrics . 27 2.2.3 Local Planning . 28 2.2.4 Collision Detection . 29 i 2.3 Sampling-based Planning Algorithms . 32 2.3.1 Randomized Potential Fields . 33 2.3.2 Ariadne's Clew . 35 2.3.3 Single-query Bidirectional Lazy (SBL) . 35 2.3.4 Probabilistic Roadmap (PRM) . 38 2.3.5 Rapidly-exploring Random Tree (RRT) . 42 3 Rapidly-exploring Random Tree Analysis 47 3.1 Simplified Models . 48 3.1.1 One-dimensional Model . 49 3.1.2 Markov Chain Model . 53 3.2 Exponential and Power Decay Regimes . 59 3.3 Parameterization and Heuristics . 65 3.3.1 Step Size . 66 3.3.2 Extend versus Connect .................... 69 3.4 Implications for Problem Difficulty . 72 3.5 Summary . 76 4 Distributions and Restarts 78 4.1 Distributions to Runtimes and Restarts . 79 4.2 Continuous Problems . 82 4.2.1 Experiments . 83 4.3 Discrete Problems . 86 4.3.1 Planner Variations . 87 4.3.2 Experiments . 87 4.4 Generalizing Restarts . 90 4.4.1 General Queries . 91 4.4.2 Task-based Decomposition . 94 ii 4.4.3 Algorithmic Measures . 98 4.5 Summary . 100 5 Neighborhood-based Expansion 101 5.1 Locally-isolated Expansion . 101 5.2 Path-length Annexed Random Tree (PART) . 104 5.3 Performance . 109 5.3.1 Demonstrative Problems . 110 5.3.2 Realistic Benchmarks . 113 5.4 Roadmaps and Paths . 117 5.5 Summary . 119 6 Local Obstacle Adaptation 121 6.1 Cost-to-come Thresholds . 121 6.2 Potentially-reachable Regions . 123 6.3 Adaptive PART (APART) . 125 6.4 Performance . 129 6.4.1 Demonstrative Problems . 130 6.4.2 Realistic Benchmarks . 132 6.5 Roadmaps and Paths . 136 6.6 Summary . 138 7 Conclusion 140 7.1 Future Work . 143 7.1.1 Extended Algorithm Models . 143 7.1.2 Informed Restart Strategies . 143 7.1.3 APART with Disconnected Components . 144 7.1.4 Balancing APART Exploration . 144 7.1.5 Collision Checking in APART Path Processing . 145 iii A Derivations 146 A.1 One-dimensional RRT Model . 146 A.1.1 Recurrence . 146 A.1.2 Distribution . 147 A.1.3 Approximations . 149 Geometric . 149 Negative Binomial . 150 A.2 Power Decay . 151 A.3 Constant Restart Intervals . 152 A.3.1 Mean . 152 A.3.2 Variance . 153 A.3.3 Usefulness . 154 A.3.4 Optimality . 154 A.4 Na¨ıve Neighbor Scaling . 155 B Implementation 156 B.1 Algorithm Terminology and Notation . 156 B.2 Software . 158 Bibliography 161 iv List of Tables 5.1 Maze (bidirectional) simulation results evaluating the PART planner. 111 5.2 Kinked tunnel (bidirectional) simulation results evaluating the PART planner. 112 5.3 Bug trap (unidirectional) simulation results evaluating the PART plan- ner...................................... 113 5.4 Flange 0:95 (unidirectional) simulation results evaluating the PART planner. 116 5.5 Alpha puzzle 1:1 (bidirectional) simulation results evaluating the PART planner. 117 6.1 Maze (bidirectional) simulation results evaluating the APART planner. 130 6.2 Kinked tunnel (bidirectional) simulation results evaluating the APART planner. 131 6.3 Bug trap (unidirectional) simulation results evaluating the APART planner. 132 6.4 Flange 0:95 (unidirectional) simulation results evaluating the APART planner. 133 6.5 Alpha puzzle 1:1 (bidirectional) simulation results evaluating the APART planner. 134 6.6 Mean local tree counts for the PART and APART planners. 137 v List of Figures 1.1 An example mapping from work space to configuration space. 16 1.2 Two-dimensional experimental problems. 20 1.3 Six-dimensional experimental problems. 20 2.1 An example of combinatorial planning for a two-dimensional setting. 25 2.2 The top four layers of an oriented bounding box hierarchy. 30 2.3 A potential field function for two dimensions. 34 2.4 Path segment trees in the SBL planner. 38 2.5 Roadmaps generated by the PRM planner. 40 2.6 Non-uniform sampling distributions for the PRM planner. 41 2.7 Trees created by the RRT planner. 43 2.8 Voronoi decompositions for in-progress instances of the RRT planner. 45 2.9 Effective sampling regions from the DD-RRT planner. 46 3.1 Setup of the one-dimensional model of the RRT planner. 50 3.2 Edge effects in the (bidirectional) RRT planner. 53 3.3 Computed performance of the RRT planner in one dimension via Markov chain fundamental matrix. 56 3.4 Example discretized Markov chain models for the RRT planner. 57 3.5 Discretized Markov chain model for the RRT planner. 59 vi 3.6 Dynamics of the RRT planner in the nine-state environment as mod- eled via Markov chain. 60 3.7 Diversely-sized minimum (Euclidean) Voronoi regions in different nar- row passage situations. 61 3.8 Generalized Voronoi region volume changes with sampling. 62 3.9 Sequence of Voronoi visibility during the RRT planner's expansion on atube.................................... 63 3.10 Transition between power and exponential decay in the RRT planner. 65 3.11 Comparison of small and large step size in the RRT planner. 67 3.12 Densities of nodes created by the RRT planner with Manhattan metric at specific iterations. 68 3.13 Densities of nodes created by the RRT planner with Euclidean metric at specific iterations. 68 3.14 Densities of nodes created by the RRT planner with Chebyshev metric at specific iterations. 69 3.15 Average-case RRT instances over metric and step size. 70 3.16 Effects of step size and heuristic on overall RRT planner performance. 72 3.17 Collision checking performance of the RRT planner on a bug trap ver- sus query states. 73 3.18 Node density in the RRT planner by performance. 74 3.19 \Trick" states for the RRT planner on realistic disassembly/assembly problems. 75 3.20 RRT planner growth bias due to faraway \trick" states. 76 4.1 Balanced universal restart strategy. 80 4.2 Restart statistical diagrams. 81 4.3 The usefulness of restarts on various versions of the kinked tunnel. 84 4.4 Restart benefits for two easier versions of the alpha puzzle. 85 vii 4.5 Impact of nearest neighbor computation method on runtimes and restarts in the RRT planner. 86 4.6 Discrete example problems. 88 4.7 Performance and restart impact for RRT variants on exchange. 89 4.8 Performance and restart impact for RRT variants on 15-puzzle. 90 4.9 Constant and universal restart strategy performance of the RRT plan- ner on the kinked tunnel with a random sequence of queries. 92 4.10 RRT planner instances solving tasks. 95 4.11 Runtime survivor functions for RRT planner solving tasks. 95 4.12 Voronoi visibility issues on the.
Load more

Recommended publications
  • HALO: Post-Link Heap-Layout Optimisation
    HALO: Post-Link Heap-Layout Optimisation Joe Savage Timothy M. Jones University of Cambridge, UK University of Cambridge, UK [email protected] [email protected] Abstract 1 Introduction Today, general-purpose memory allocators dominate the As the gap between memory and processor speeds continues landscape of dynamic memory management. While these so- to widen, efficient cache utilisation is more important than lutions can provide reasonably good behaviour across a wide ever. While compilers have long employed techniques like range of workloads, it is an unfortunate reality that their basic-block reordering, loop fission and tiling, and intelligent behaviour for any particular workload can be highly subop- register allocation to improve the cache behaviour of pro- timal. By catering primarily to average and worst-case usage grams, the layout of dynamically allocated memory remains patterns, these allocators deny programs the advantages of largely beyond the reach of static tools. domain-specific optimisations, and thus may inadvertently Today, when a C++ program calls new, or a C program place data in a manner that hinders performance, generating malloc, its request is satisfied by a general-purpose allocator unnecessary cache misses and load stalls. with no intimate knowledge of what the program does or To help alleviate these issues, we propose HALO: a post- how its data objects are used. Allocations are made through link profile-guided optimisation tool that can improve the fixed, lifeless interfaces, and fulfilled by
    [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]
  • 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]
  • Declarative Computation Model Memory Management Last Call
    Memory Management Declarative Computation Model Memory management (VRH 2.5) • Semantic stack and store sizes during computation – analysis using operational semantics Carlos Varela – recursion used for looping RPI • efficient because of last call optimization October 5, 2006 – memory life cycle Adapted with permission from: – garbage collection Seif Haridi KTH Peter Van Roy UCL C. Varela; Adapted w/permission from S. Haridi and P. Van Roy 1 C. Varela; Adapted w/permission from S. Haridi and P. Van Roy 2 Last call optimization Last call optimization • Consider the following procedure ST: [ ({Loop10 0}, E0) ] proc {Loop10 I} ST: [({Browse I}, {I→i ,...}) proc {Loop10 I} 0 if I ==10 then skip ({Loop10 I+1}, {I→i ,...}) ] else if I ==10 then skip 0 else σ : {i =0, ...} {Browse I} 0 {Browse I} Recursive call {Loop10 I+1} {Loop10 I+1} end is the last call end ST: [({Loop10 I+1}, {I→i0,...}) ] end end σ : {i0=0, ...} • This procedure does not increase the size of the STACK ST: [({Browse I}, {I→i1,...}) • It behaves like a looping construct ({Loop10 I+1}, {I→i1,...}) ] σ : {i0=0, i1=1,...} C. Varela; Adapted w/permission from S. Haridi and P. Van Roy 3 C. Varela; Adapted w/permission from S. Haridi and P. Van Roy 4 Stack and Store Size Garbage collection proc {Loop10 I} proc {Loop10 I} ST: [({Browse I}, {I→ik,...}) ST: [({Browse I}, {I→ik,...}) if I ==10 then skip if I ==10 then skip ({Loop10 I+1}, {I i ,...}) ] ({Loop10 I+1}, {I i ,...}) ] else → k else → k {Browse I} σ : {i0=0, i1=1,..., ik-i=k-1, ik=k,..
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]
  • Cryptographic Software: Vulnerabilities in Implementations 1
    Pobrane z czasopisma Annales AI- Informatica http://ai.annales.umcs.pl Data: 03/10/2021 00:10:27 Annales UMCS Informatica AI XI, 4 (2011) 1–10 DOI: 10.2478/v10065-011-0030-7 Cryptographic software: vulnerabilities in implementations Michał Łuczaj1∗ 1Institute of Telecommunications, Warsaw University of Technology Poland Abstract – Security and cryptographic applications or libraries, just as any other generic software products may be affected by flaws introduced during the implementation process. No matter how much scrutiny security protocols have undergone, it is — as always — the weakest link that holds everything together to makes products secure. In this paper I take a closer look at problems usually resulting from a simple human made mistakes, misunderstanding of algorithm details or a plain lack of experience with tools and environment. In other words: everything that can and will happen during software development but in the fragile context of cryptography. UMCS1 Introduction I begin with a brief introduction of typical mistakes and oversights that can be made during program implementation in one of the most popular programming languages, C[1]. I also explain the concept of exploitable memory corruption, how critical it is and where it leads from the attacker’s point of view. A set of real-world examples is given. Some well known previously disclosed vulner- abilities are brought to illustrate how a flaw (sometimes even an innocent looking) can fatally injune security of the whole protocol, algorithm. There is much to discuss as failed attempts at implementing cryptographic primitives — or making use of cryptog- raphy in general — range broadly.
    [Show full text]
  • Memory Management
    Memory management The memory of a computer is a finite resource. Typical Memory programs use a lot of memory over their lifetime, but not all of it at the same time. The aim of memory management is to use that finite management resource as efficiently as possible, according to some criterion. Advanced Compiler Construction In general, programs dynamically allocate memory from two different areas: the stack and the heap. Since the Michel Schinz — 2014–04–10 management of the stack is trivial, the term memory management usually designates that of the heap. 1 2 The memory manager Explicit deallocation The memory manager is the part of the run time system in Explicit memory deallocation presents several problems: charge of managing heap memory. 1. memory can be freed too early, which leads to Its job consists in maintaining the set of free memory blocks dangling pointers — and then to data corruption, (also called objects later) and to use them to fulfill allocation crashes, security issues, etc. requests from the program. 2. memory can be freed too late — or never — which leads Memory deallocation can be either explicit or implicit: to space leaks. – it is explicit when the program asks for a block to be Due to these problems, most modern programming freed, languages are designed to provide implicit deallocation, – it is implicit when the memory manager automatically also called automatic memory management — or garbage tries to free unused blocks when it does not have collection, even though garbage collection refers to a enough free memory to satisfy an allocation request. specific kind of automatic memory management.
    [Show full text]
  • Eviction Based on Implicit Entry Reachability
    University of Texas at El Paso ScholarWorks@UTEP Open Access Theses & Dissertations 2020-01-01 Finalcache: Eviction Based On Implicit Entry Reachability Adrian Veliz University of Texas at El Paso Follow this and additional works at: https://scholarworks.utep.edu/open_etd Part of the Computer Sciences Commons, and the Sustainability Commons Recommended Citation Veliz, Adrian, "Finalcache: Eviction Based On Implicit Entry Reachability" (2020). Open Access Theses & Dissertations. 3128. https://scholarworks.utep.edu/open_etd/3128 This is brought to you for free and open access by ScholarWorks@UTEP. It has been accepted for inclusion in Open Access Theses & Dissertations by an authorized administrator of ScholarWorks@UTEP. For more information, please contact [email protected]. FINALCACHE: EVICTION BASED ON IMPLICIT ENTRY REACHABILITY ADRIAN EDWARD VELIZ Doctoral Program in Computer Science APPROVED: Eric Freudenthal, Ph.D., Chair Omar Badreddin, Ph.D. Yoonsik Cheon, Ph.D. Art Duval, Ph.D. Stephen L. Crites, Jr., Ph.D. Dean of the Graduate School Copyright © by Adrian Veliz 2020 Dedication This dissertation is dedicated to my brother Oscar, mother Martha, and father Jesus. Your love and support mean the world to me. This would not have been possible without you. Love you. FINALCAHCE: EVICTION BASED ON IMPLICIT ENTRY REACHABILITY by ADRIAN EDWARD VELIZ, B.S. & M.S. OF CS DISSERTATION Presented to the Faculty of the Graduate School of The University of Texas at El Paso in Partial Fulfillment of the Requirements for the Degree of DOCTOR OF PHILOSOPHY Department of Computer Science THE UNIVERSITY OF TEXAS AT EL PASO August 2020 Acknowledgements I would like to thank everyone who has helped me with research and writing.
    [Show full text]
  • Mitigating the Performance-Efficiency Tradeoff in Resilient Memory Disaggregation
    Mitigating the Performance-Efficiency Tradeoff in Resilient Memory Disaggregation Youngmoon Lee∗, Hasan Al Maruf∗, Mosharaf Chowdhury∗, Asaf Cidonx, Kang G. Shin∗ University of Michigan∗ Columbia Universityx ABSTRACT State-of-the-art solutions take three primary approaches: (i) local We present the design and implementation of a low-latency, low- disk backup [36, 66], (ii) remote in-memory replication [31, 50], and overhead, and highly available resilient disaggregated cluster mem- (iii) remote in-memory erasure coding [61, 64, 70, 73] and compres- ory. Our proposed framework can access erasure-coded remote sion [45]. Unfortunately, they suffer from some combinations of memory within a single-digit `s read/write latency, significantly the following problems. improving the performance-efficiency tradeoff over the state-of- High latency: The first approach has no additional memory the-art – it performs similar to in-memory replication with 1.6× overhead, but the access latency is intolerably high in the presence lower memory overhead. We also propose a novel coding group of any of the aforementioned failure scenarios. The systems that placement algorithm for erasure-coded data, that provides load bal- take the third approach do not meet the single-digit `s latency ancing while reducing the probability of data loss under correlated requirement of disaggregated cluster memory even when paired failures by an order of magnitude. with RDMA (Figure 1). High cost: While the second approach has low latency, it dou- bles memory consumption as well as network bandwidth require- ments. The first and second approaches represent the two extreme 1 INTRODUCTION points in the performance-vs-efficiency tradeoff space for resilient To address the increasing memory pressure in datacenters, two cluster memory (Figure 1).
    [Show full text]
  • Garbage Collection
    GARBAGE COLLECTION Prof. Chris Jermaine [email protected] Prof. Scott Rixner [email protected] 1 What Is Garbage Collection? • A “garbage collected” PL implementation (like Java)... — Provides automatic support for reclaiming memory you are done with — The imp itself checks to see if there is any way to reach some allocated memory — And if there is not, it deletes it • Key thing to be aware of: — It’s a bit strong to say a “language” itself is garbage collected (or not) — Though that is what we (and everyone else) will say — Why is the claim that “C is not garbage collected” a bit silly? • What is alternative to GC? — Ask the programmer to free memory when done with it. Always have: SparseDoubleVector foo = new SparsDoubleVector (100, 1.0) some code; delete foo; 2 Short History of Garbage Collection • Way back when, there was no dynamic memory allocation — We’re talking Fortran in the mid 1950’s — You declared all your vars up front, at compile time — So no need for PL system to dynamically reclaim memory... — In first implementations, compiler claimed space for each var • GC was invented with Lisp in the late 1950s — But remained a fringe idea — Lisp was never tremendously popular — Then, with advent of C/C++ in early 70’s, self-memory management was “in” • I’d say it only became mainstream with first Java in mid 90’s — Now, a very common idea 3 Pros And Cons of GC • Pros? Cons? 4 Pros And Cons of GC • Pros — Don’t need to worry about adding “free” or “delete” statements to code — Never have bugs related to dangling references/pointers
    [Show full text]
  • Automatic Memory Management Policies for Low Power, Memory Limited, and Delay Intolerant Devices Md Abu Jahid University of Texas at El Paso, [email protected]
    University of Texas at El Paso DigitalCommons@UTEP Open Access Theses & Dissertations 2013-01-01 Automatic Memory Management Policies For Low Power, Memory Limited, And Delay Intolerant Devices Md Abu Jahid University of Texas at El Paso, [email protected] Follow this and additional works at: https://digitalcommons.utep.edu/open_etd Part of the Computer Sciences Commons, and the Oil, Gas, and Energy Commons Recommended Citation Jahid, Md Abu, "Automatic Memory Management Policies For Low Power, Memory Limited, And Delay Intolerant Devices" (2013). Open Access Theses & Dissertations. 1849. https://digitalcommons.utep.edu/open_etd/1849 This is brought to you for free and open access by DigitalCommons@UTEP. It has been accepted for inclusion in Open Access Theses & Dissertations by an authorized administrator of DigitalCommons@UTEP. For more information, please contact [email protected]. AUTOMATIC MEMORY MANAGEMENT POLICIES FOR LOW POWER, MEMORY LIMITED, AND DELAY INTOLERANT DEVICES MD ABU JAHID Department of Computer Science APPROVED: Eric Freudenthal, Chair, Ph.D. Luc Longpr´e,Ph.D. Bryan Usevitch, Ph.D. Salamah I. Salamah, Ph.D. Benjamin C. Flores, Ph.D. Dean of the Graduate School c Copyright by Md Abu Jahid 2013 to my PARENTS with love AUTOMATIC MEMORY MANAGEMENT POLICIES FOR LOW POWER, MEMORY LIMITED, AND DELAY INTOLERANT DEVICES by MD ABU JAHID THESIS Presented to the Faculty of the Graduate School of The University of Texas at El Paso in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE Department of Computer Science THE UNIVERSITY OF TEXAS AT EL PASO August 2013 Acknowledgements I would like to express my gratitude to my advisor, Dr.
    [Show full text]
  • Garbage Collection Hoping to Cover Motivation Garbage Collection (GC)
    Hoping to cover Garbage Collection ! Motivation & basics ! Introduction to three families of collection algorithms: ! Reference Counting ! Mark & Sweep Andrew Tolmach ! Copying Collection ! Advanced issues and topics (Slides prepared by Marius Nita.) 1 2 Motivation Garbage Collection (GC) Problems with manual memory management: ! The automatic reclamation of unreachable memory (aka garbage). ! It is extremely tedious and error-prone. ! Universally used for high level languages with closures ! It introduces software engineering issues (Who is and complex data structures that are allocated supposed to free the memory?) implicitly. ! It is by no means intrinsically efficient. (free is not free.) ! Useful for any language that supports heap allocation. ! In many cases, the costs outweigh the benefits. ! It removes the need for explicit deallocation (no more delete and free). ! Let the GC implementor deal with memory corruption issues once and for all. 3 4 How does it work? Terminology Typically: Heap: Adirectedgraphwhosenodesaredynamically ! The user program (mutator)islinkedagainstalibrary allocated records and whose edges are pointers between known as the runtime system (RTS) (e.g. libc). nodes. Typically laid out in a contiguous memory space. ! In the RTS resides the memory allocation service,which Root set: The set of pointers into the heap from an external exposes an allocation routine to the user program. source (e.g. the stack, global variables). ! When the user program desires more memory, it Live data: The set of heap records that are reachable by invokes the allocation routine (e.g. malloc). following paths starting at members of the root set. ! The allocation service may then perform a collection to Garbage: The set of heap records that are not live.
    [Show full text]