DOCSLIB.ORG

Uniprocessor Garbage Collection Techniques

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Unipro cessor Garbage Collection Techniques Submitted to ACM Computing Surveys Paul R Wilson Abstract Incremental Tracing Collectors Coherence and Conservatism We survey basic garbage collection algorithms and Tricolor Marking variations such as incremental and generational collec Incremental approaches tion we then discuss lowlevel implementation consid Write Barrier Algorithms erations and the relationships b etween storage man Snapshotatb eginning agement systems languages and compilers Through Algorithms out we attempt to present a unied view based on Incremental Up date WriteBar abstract traversal strategies addressing issues of con rier Algorithms servatism opp ortunism and immediacy of reclama Bakers Read Barrier Algorithms tion we also p ointoutavariety of implementation Incremental Copying details that are likely to have a signicant impact on ers Incremental Noncopy Bak p erformance ing AlgorithmThe Treadmill Conservatism of Bakers Read Barrier Contents Variations on the Read Barrier Replication Copying Collection Automatic Storage Reclamation Coherence and Conservatism Revisited Motivation Coherence and Conservatism in The TwoPhase Abstraction Noncopying collection Ob ject Representations Coherence and Conservatism in Copying Collection Overview of the Pap er Radical Collection and Op Basic Garbage Collection Techniques p ortunistic Tracing Comparing Incremental Techniques Reference Counting Realtime Tracing Collection The Problem with Cycles Ro ot Set Scanning The Eciency Problem Guaranteeing Sucient Progress Deferred Reference Counting Trading worstcase p erformance V ariations on Reference Counting for exp ected p erformance MarkSweep Collection Discussion MarkCompact Collection Cho osing an Incremental Algorithm Copying Garbage Collection A Simple Copying Collector Generational Garbage Collection StopandCopy Using Semi Multiple Subheaps with Varying Col spaces lection Frequencies Eciency of Copying Collection AdvancementPolicies NonCopying Implicit Collection Heap Organization Cho osing Among Basic Tracing Tech Subareas in copying schemes niques Generations in Noncopying Problems with Simple Tracing Collectors Schemes Conservatism in Garbage Collection Discussion Tracking Intergenerational References Automatic Storage Reclama Indirection Tables tion Ungars Remembered Sets Garbage col lection is the automatic reclamation of Page Marking computer storage Knu Coh App While in Word marking many systems programmers must explicitly reclaim Card Marking heap memory at some p oint in the program byus Store Lists ing a free or disp ose statement garbage collected Discussion systems free the programmer from this burden The The Generational Principle Revisited garbage collectors function is to nd data ob jects Pitfalls of Generational Collection that are no longer in use and make their space avail The Pig in the Snake Problem able for reuse by the the running program An ob ject Small Heapallo cated Ob jects is considered garbage and sub ject to reclamation if it is not reachable by the running program via any path Large Ro ot Sets of p ointer traversals Live p otentially reachable ob Realtime Generational Collection jects are preserved by the collector ensuring that the program can never traverse a dangling p ointer into Lo cality Considerations a deallo cated ob ject Varieties of Lo cality Eects This pap er surveys basic and advanced techniques Lo cality of Allo cation and Shortlived in unipro cessor garbage collectors esp ecially those de ob jects velop ed in the last decade For a more thorough Lo calityofTracing Traversals treatment of older techniques see Knu Coh Clustering of LongerLived Ob jects While it do es not cover parallel or distributed col Static Grouping lection it presents a unied taxonomy of incremen Dynamic Reorganization tal techniques whichlays the groundwork for under standing parallel and distributed collection Our fo Co ordination with Paging cus is on garbage collection for pro cedural and ob ject oriented languages but much of the information here Lowlevel Implementation Issues will serveasbackground for understanding garbage Pointer Tags and Ob ject Headers collection of other kinds of systems such as functional ConservativePointer Finding or logic programming languages For further reading Linguistic Supp ort and Smart Pointers on various advanced topics in garbage collection the Compiler Co op eration and Optimizations pap ers collected in BC are a go o d starting p oint GCAnytime vs SafePoints Collection Motivation Partitioned Register Sets vs Variable Rep Garbage collection is necessary for fully mo dular pro resentation Recording gramming to avoid intro ducing unnecessary inter mo dule dep endencies Asoftware routine op erating Optimization of Garbage Col on a data structure should not havetodependwhat lection Itself Free Storage Management We use the term heap in the simple sense of a storage managementtechnique whichallows any dynamically allo cated Compact Representations of Heap Data ob ject to b e freed at any timethis is not to b e confused with heap data structures which maintain ordering constraints GCrelated Language Features We use the term ob ject lo osely to include anykindof structured data record suchasPascal records or C structs as Weak Pointers well as fulledged ob jects with encapsulation and inheritance Finalization in the sense of ob jectoriented programming Multiple DifferentlyManaged Heaps There is also a rep ository of pap ers in PostScript for mat available for anonymous Internet FTP from our FTP host csutexasedupubgarbage Among other things this Overall Cost of Garbage Collection rep ository contains collected pap ers from several garbage col lection workshops held in conjunction with ACM OOPSLA conferences Conclusions and Areas for Research other routines may b e op erating on the same struc grammers nd the source of leaked ob jects in lan ture unless there is some go o d reason to co ordinate guages with explicit deallo cation HJ and these can their activities If ob jects must b e deallo cated explic b e extremely valuable Unfortunately these to ols only itly some mo dule must b e resp onsible for knowing nd actual leaks during particular program runs not when other mo dules are not interested in a particular p ossible leaks due to uncommon execution patterns ob ject Finding the source of a leaked ob ject do es not always solve the problem either the programmer still must Since livenessisaglobal prop erty this intro duces b e able to determine a p oint where the ob ject should nonlo cal b o okkeeping into routines that might other b e deallo catedif one exists If one do esnt exist the wise b e lo cally understandable and exibly comp os program must b e restructured This kind of gar able This b o okkeeping inhibits abstraction and re bage debugging is b etter than nothing but it is very duces extensibility b ecause when new functionalityis fallible and it must b e rep eated whenever programs implemented the b o okkeeping co de must b e up dated change it is desirable to actually eliminate leaks in The runtime cost of the b o okkeeping itself may b e sig general rather than certain detectable leaks in partic nicant and in some cases it mayintro duce the need ular for additional synchronization in concurrent applica tions Explicit allo cation and reclamation lead to program The unnecessary complications and subtle interac errors in more subtle ways as well It is common for tions created by explicit storage allo cation are esp e programmers to allo cate a mo derate number of ob cially troublesome b ecause programming mistakes of jects statically so that it is unnecessary to allo cate ten break the basic abstractions of the programming them on the heap and decide when and where to re language making errors hard to diagnose Failing to claim them This leads to xed limitations on pro reclaim memory at the prop er p ointmayleadtoslow grams making them fail when those limitations are memory leaks with unreclaimed memory gradually ac exceeded p ossibly years later when computer memo cumulating until the pro cess terminates or swap space ries and data sets are much larger This brittleness is exhausted Reclaiming memory to o so on can lead to makes co de much less reusable b ecause the undo cu very strange b ehavior b ecause an ob jects space may mented limits cause it to fail even if its b eing used in b e reused to store a completely dierent ob ject while away consistent with its abstractions For example an old p ointer still exists The same memory may many compilers fail when faced with automatically therefore b e interpreted as two dierent ob jects simul generated programs that violate assumptions ab out taneously with up dates to one causing unpredictable normal programming practices mutations of the other These problems lead many applications program These programming errors are particularly dan mers to implement some form of applicationsp ecic gerous b ecause they often fail to show up rep eat garbage collection within a large software system to ably making debugging very dicultthey maynever avoid most of the headaches of explicit storage man show up at all until the program is stressed in an
Recommended publications
  • Memory Safety Without Garbage Collection for Embedded Applications

    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

    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.
  • An Efficient Framework for Implementing Persistent Data Structures on Asymmetric NVM Architecture

    An Efficient Framework for Implementing Persistent Data Structures on Asymmetric NVM Architecture

    AsymNVM: An Efficient Framework for Implementing Persistent Data Structures on Asymmetric NVM Architecture Teng Ma Mingxing Zhang Kang Chen∗ [email protected] [email protected] [email protected] Tsinghua University Tsinghua University & Sangfor Tsinghua University Beijing, China Shenzhen, China Beijing, China Zhuo Song Yongwei Wu Xuehai Qian [email protected] [email protected] [email protected] Alibaba Tsinghua University University of Southern California Beijing, China Beijing, China Los Angles, CA Abstract We build AsymNVM framework based on AsymNVM ar- The byte-addressable non-volatile memory (NVM) is a promis- chitecture that implements: 1) high performance persistent ing technology since it simultaneously provides DRAM-like data structure update; 2) NVM data management; 3) con- performance, disk-like capacity, and persistency. The cur- currency control; and 4) crash-consistency and replication. rent NVM deployment with byte-addressability is symmetric, The key idea to remove persistency bottleneck is the use of where NVM devices are directly attached to servers. Due to operation log that reduces stall time due to RDMA writes and the higher density, NVM provides much larger capacity and enables efficient batching and caching in front-end nodes. should be shared among servers. Unfortunately, in the sym- To evaluate performance, we construct eight widely used metric setting, the availability of NVM devices is affected by data structures and two transaction applications based on the specific machine it is attached to. High availability canbe AsymNVM framework. In a 10-node cluster equipped with achieved by replicating data to NVM on a remote machine. real NVM devices, results show that AsymNVM achieves However, it requires full replication of data structure in local similar or better performance compared to the best possible memory — limiting the size of the working set.
  • S-Algol Reference Manual Ron Morrison

    S-Algol Reference Manual Ron Morrison

    S-algol Reference Manual Ron Morrison University of St. Andrews, North Haugh, Fife, Scotland. KY16 9SS CS/79/1 1 Contents Chapter 1. Preface 2. Syntax Specification 3. Types and Type Rules 3.1 Universe of Discourse 3.2 Type Rules 4. Literals 4.1 Integer Literals 4.2 Real Literals 4.3 Boolean Literals 4.4 String Literals 4.5 Pixel Literals 4.6 File Literal 4.7 pntr Literal 5. Primitive Expressions and Operators 5.1 Boolean Expressions 5.2 Comparison Operators 5.3 Arithmetic Expressions 5.4 Arithmetic Precedence Rules 5.5 String Expressions 5.6 Picture Expressions 5.7 Pixel Expressions 5.8 Precedence Table 5.9 Other Expressions 6. Declarations 6.1 Identifiers 6.2 Variables, Constants and Declaration of Data Objects 6.3 Sequences 6.4 Brackets 6.5 Scope Rules 7. Clauses 7.1 Assignment Clause 7.2 if Clause 7.3 case Clause 7.4 repeat ... while ... do ... Clause 7.5 for Clause 7.6 abort Clause 8. Procedures 8.1 Declarations and Calls 8.2 Forward Declarations 2 9. Aggregates 9.1 Vectors 9.1.1 Creation of Vectors 9.1.2 upb and lwb 9.1.3 Indexing 9.1.4 Equality and Equivalence 9.2 Structures 9.2.1 Creation of Structures 9.2.2 Equality and Equivalence 9.2.3 Indexing 9.3 Images 9.3.1 Creation of Images 9.3.2 Indexing 9.3.3 Depth Selection 9.3.4 Equality and Equivalence 10. Input and Output 10.1 Input 10.2 Output 10.3 i.w, s.w and r.w 10.4 End of File 11.
  • Efficient Support of Position Independence on Non-Volatile Memory

    Efficient Support of Position Independence on Non-Volatile Memory

    Efficient Support of Position Independence on Non-Volatile Memory Guoyang Chen Lei Zhang Richa Budhiraja Qualcomm Inc. North Carolina State University Qualcomm Inc. [email protected] Raleigh, NC [email protected] [email protected] Xipeng Shen Youfeng Wu North Carolina State University Intel Corp. Raleigh, NC [email protected] [email protected] ABSTRACT In Proceedings of MICRO-50, Cambridge, MA, USA, October 14–18, 2017, This paper explores solutions for enabling efficient supports of 13 pages. https://doi.org/10.1145/3123939.3124543 position independence of pointer-based data structures on byte- addressable None-Volatile Memory (NVM). When a dynamic data structure (e.g., a linked list) gets loaded from persistent storage into 1 INTRODUCTION main memory in different executions, the locations of the elements Byte-Addressable Non-Volatile Memory (NVM) is a new class contained in the data structure could differ in the address spaces of memory technologies, including phase-change memory (PCM), from one run to another. As a result, some special support must memristors, STT-MRAM, resistive RAM (ReRAM), and even flash- be provided to ensure that the pointers contained in the data struc- backed DRAM (NV-DIMMs). Unlike on DRAM, data on NVM tures always point to the correct locations, which is called position are durable, despite software crashes or power loss. Compared to independence. existing flash storage, some of these NVM technologies promise This paper shows the insufficiency of traditional methods in sup- 10-100x better performance, and can be accessed via memory in- porting position independence on NVM. It proposes a concept called structions rather than I/O operations.
  • Data Structures Are Ways to Organize Data (Informa- Tion). Examples

    Data Structures Are Ways to Organize Data (Informa- Tion). Examples

    CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 1 ] What are Data Structures? Data structures are ways to organize data (informa- tion). Examples: simple variables — primitive types objects — collection of data items of various types arrays — collection of data items of the same type, stored contiguously linked lists — sequence of data items, each one points to the next one Typically, algorithms go with the data structures to manipulate the data (e.g., the methods of a class). This course will cover some more complicated data structures: how to implement them efficiently what they are good for CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 2 ] Abstract Data Types An abstract data type (ADT) defines a state of an object and operations that act on the object, possibly changing the state. Similar to a Java class. This course will cover specifications of several common ADTs pros and cons of different implementations of the ADTs (e.g., array or linked list? sorted or unsorted?) how the ADT can be used to solve other problems CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 3 ] Specific ADTs The ADTs to be studied (and some sample applica- tions) are: stack evaluate arithmetic expressions queue simulate complex systems, such as traffic general list AI systems, including the LISP language tree simple and fast sorting table database applications, with quick look-up CPSC 211 Data Structures & Implementations (c) Texas A&M University [ 4 ] How Does C Fit In? Although data structures are universal (can be imple- mented in any programming language), this course will use Java and C: non-object-oriented parts of Java are based on C C is not object-oriented We will learn how to gain the advantages of data ab- straction and modularity in C, by using self-discipline to achieve what Java forces you to do.
  • 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

    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.
  • Software II: Principles of Programming Languages

    Software II: Principles of Programming Languages

    Software II: Principles of Programming Languages Lecture 6 – Data Types Some Basic Definitions • A data type defines a collection of data objects and a set of predefined operations on those objects • A descriptor is the collection of the attributes of a variable • An object represents an instance of a user- defined (abstract data) type • One design issue for all data types: What operations are defined and how are they specified? Primitive Data Types • Almost all programming languages provide a set of primitive data types • Primitive data types: Those not defined in terms of other data types • Some primitive data types are merely reflections of the hardware • Others require only a little non-hardware support for their implementation The Integer Data Type • Almost always an exact reflection of the hardware so the mapping is trivial • There may be as many as eight different integer types in a language • Java’s signed integer sizes: byte , short , int , long The Floating Point Data Type • Model real numbers, but only as approximations • Languages for scientific use support at least two floating-point types (e.g., float and double ; sometimes more • Usually exactly like the hardware, but not always • IEEE Floating-Point Standard 754 Complex Data Type • Some languages support a complex type, e.g., C99, Fortran, and Python • Each value consists of two floats, the real part and the imaginary part • Literal form real component – (in Fortran: (7, 3) imaginary – (in Python): (7 + 3j) component The Decimal Data Type • For business applications (money)
  • Purely Functional Data Structures

    Purely Functional Data Structures

    Purely Functional Data Structures Chris Okasaki September 1996 CMU-CS-96-177 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Thesis Committee: Peter Lee, Chair Robert Harper Daniel Sleator Robert Tarjan, Princeton University Copyright c 1996 Chris Okasaki This research was sponsored by the Advanced Research Projects Agency (ARPA) under Contract No. F19628- 95-C-0050. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of ARPA or the U.S. Government. Keywords: functional programming, data structures, lazy evaluation, amortization For Maria Abstract When a C programmer needs an efficient data structure for a particular prob- lem, he or she can often simply look one up in any of a number of good text- books or handbooks. Unfortunately, programmers in functional languages such as Standard ML or Haskell do not have this luxury. Although some data struc- tures designed for imperative languages such as C can be quite easily adapted to a functional setting, most cannot, usually because they depend in crucial ways on as- signments, which are disallowed, or at least discouraged, in functional languages. To address this imbalance, we describe several techniques for designing functional data structures, and numerous original data structures based on these techniques, including multiple variations of lists, queues, double-ended queues, and heaps, many supporting more exotic features such as random access or efficient catena- tion. In addition, we expose the fundamental role of lazy evaluation in amortized functional data structures.
  • Lecture Notes in Computer Science

    Lecture Notes in Computer Science

    Orthogonal Persistence Revisited Alan Dearle, Graham N.C. Kirby and Ron Morrison School of Computer Science, University of St Andrews, North Haugh, St Andrews, Fife KY16 9SX, Scotland {al, graham, ron}@cs.st-andrews.ac.uk Abstract. The social and economic importance of large bodies of programs and data that are potentially long-lived has attracted much attention in the commercial and research communities. Here we concentrate on a set of methodologies and technologies called persistent programming. In particular we review programming language support for the concept of orthogonal persistence, a technique for the uniform treatment of objects irrespective of their types or longevity. While research in persistent programming has become unfashionable, we show how the concept is beginning to appear as a major component of modern systems. We relate these attempts to the original principles of orthogonal persistence and give a few hints about how the concept may be utilised in the future. 1 Introduction The aim of persistent programming is to support the design, construction, maintenance and operation of long-lived, concurrently accessed and potentially large bodies of data and programs. When research into persistent programming began, persistent application systems were supported by disparate mechanisms, each based upon different philosophical assumptions and implementation technologies [1]. The mix of technologies typically included naming, type and binding schemes combined with different database systems, storage architectures and query languages. The incoherence in these technologies increased the cost both intellectually and mechanically of building persistent application systems. The complexity distracted the application builder from the task in hand to concentrate on mastering the multiplicity of programming systems, and the mappings amongst them, rather than the application being developed.
  • Heapmon: a Low Overhead, Automatic, and Programmable Memory Bug Detector ∗

    Heapmon: a Low Overhead, Automatic, and Programmable Memory Bug Detector ∗

    Appears in the Proceedings of the First IBM PAC2 Conference HeapMon: a Low Overhead, Automatic, and Programmable Memory Bug Detector ∗ Rithin Shetty, Mazen Kharbutli, Yan Solihin Milos Prvulovic Dept. of Electrical and Computer Engineering College of Computing North Carolina State University Georgia Institute of Technology frkshetty,mmkharbu,[email protected] [email protected] Abstract memory bug detection tool, improves debugging productiv- ity by a factor of ten, and saves $7,000 in development costs Detection of memory-related bugs is a very important aspect of the per programmer per year [10]. Memory bugs are not easy software development cycle, yet there are not many reliable and ef- to find via code inspection because a memory bug may in- ficient tools available for this purpose. Most of the tools and tech- volve several different code fragments which can even be in niques available have either a high performance overhead or require different files or modules. The compiler is also of little help a high degree of human intervention. This paper presents HeapMon, in finding heap-related memory bugs because it often fails to a novel hardware/software approach to detecting memory bugs, such fully disambiguate pointers [18]. As a result, detection and as reads from uninitialized or unallocated memory locations. This new identification of memory bugs must typically be done at run- approach does not require human intervention and has only minor stor- time [1, 2, 3, 4, 6, 7, 8, 9, 11, 13, 14, 18]. Unfortunately, the age and execution time overheads. effects of a memory bug may become apparent long after the HeapMon relies on a helper thread that runs on a separate processor bug has been triggered.
  • This Thesis Has Been Submitted in Fulfilment of the Requirements for a Postgraduate Degree (E.G

    This Thesis Has Been Submitted in Fulfilment of the Requirements for a Postgraduate Degree (E.G

    This thesis has been submitted in fulfilment of the requirements for a postgraduate degree (e.g. PhD, MPhil, DClinPsychol) at the University of Edinburgh. Please note the following terms and conditions of use: • This work is protected by copyright and other intellectual property rights, which are retained by the thesis author, unless otherwise stated. • A copy can be downloaded for personal non-commercial research or study, without prior permission or charge. • This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the author. • The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the author. • When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given. EVALUATION OF FUNCTIONAL DATA MODELS FOR DATABASE DESIGN AND USE by KRISHNARAO GURURAO KULKARNI Ph. D. University of Edinburgh 1983 To my wife, Rama and daughter, Bhuvana Acknowledgements I am deeply indebted to my thesis supervisor, Dr. Malcolm Atkinson, for his constant guidance, help, and encouragement. for his highly incisive comments on the writing of this thesis, and for a host of other reasons. It is indeed a great pleasure to acknowledge his contribution. I am also greatly indebted to Dr. David Rees, who supervised me during the initial six months. His help and guidance during that time was invaluable. I am thankful to many of my friends In the Department for their kind advice from time to time. In particular, I would like to thank Paul Cockshott, Ken Chisholm, Pedro Hepp, Segun Owoso, George Ross, and Rob Procter for many useful discussions.