DOCSLIB.ORG

Key Tools and Technologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Key Tools and Technologies iOS 5: KEY TOOLS AND TECHNOLOGIES RICHARD WARREN CHAPTER 1 Automatic Reference Counting (ARC) In the past, memory management has been one of the most challenging parts of iOS development. ARC helps simplify memory management, by analyzing your code and automatically inserting the necessary retain, release, and autorelease method calls. Memory Management Basics •Local variables are created on the stack. They are automatically deleted once the current function returns. •To store a value beyond the current function, you must allocate memory on the heap. That value will then remain until we release them. •All Objective-C objects are created on the heap. In Objective-C, when we talk about memory management, we are typically talking about managing objects on the heap. •There are two main memory management errors: •Forgetting to release memory on the heap creates a memory leak. •Releasing memory too early, then trying to access it again creates a dangling pointer. •In the most simple examples, memory management seems easy. However, in any real-world application, it is often difficult to determine who should be responsible for allocating and releasing the required memory. 2 Retain and Release We manage the lifecycle of Objective-C objects using their retain count. •All Objects start with a retain count of 1. •Calling retain on an object, increases its retain count by 1. •Calling release, decreases its retain count. •Calling autorelease reduces the object’s retain count by 1 at some point in the future (usually at the end of the current run loop). •When the retain count hits 0, the object is deallocated. •If you create an object using a method whose name begins with alloc, new, copy, or mutableCopy, you own the object. You must release it when you are done. •If you receive an object using any other method, you must retain the object if you wish to keep it past the current method call. •You can get more information on manual memory management in Apple’s Advanced Memory Management Programming Guide. 3 Problems with Manual Memory Management Manual retain and release (MRR) has served Objective-C well for over 3 decades. It’s a solid system and has been used to create hundreds of thousands of high-quality applications. However, MRR still has a few problems. •Inserting the correct retain, release and autorelease calls is tedious. •The developer must constantly think about where their objects are coming from. Do they own the objects, or will the objects be autoreleased. •The manual memory management must be correct 100% of the time. Even one mistake can cause a memory leak or dangling pointer. •The developer’s energy and attention could be better spent solving interesting problems, not managing memory. •You can also create retain cycles. If two objects retain each other, they will never be released. •Apple has provided a number of tools, like Instruments, to track memory usage and help eliminate memory bugs. •Still, memory-related bugs are the #1 reason why iOS applications crash. 4 Garbage Collection To address these problems, Apple introduced garbage collection with Mac OS X 10.5, Leopard. •A garbage collector runs on a low-priority background thread. •It monitors all references to Objective-C objects. •When it determines that an object is no longer being used by the application, it deallocates the object. •This greatly simplified developing applications for the Mac, but it has some problems. •Developers have very little control over when and how the garbage collector runs. •If objects are rapidly created and released, memory usage can spike, causing the application to use too much memory, before the garbage collector can catch up. •Alternatively, the garbage collector may unexpectedly run, slowing down the application at a critical moment. •Most importantly, garbage collection is not available for iOS. 5 Introducing ARC ARC is a compiler feature that provides automated memory management for Objective-C objects. Conceptually, ARC follows the retain and release memory management conventions. As your project compiles, ARC analyzes the code and automatically adds the necessary retain, release, and autorelease method calls. •ARC largely frees developers from worrying about memory management. •Memory management is handled at compile-time. •There are no unexpected slowdowns during the application’s execution. •The developer maintains control over when and how objects are deleted from memory. •Apple has also optimized memory management under ARC. Basic retain and release calls are 2.5 times faster than MRR, and auto release pools can be up to 6x faster. •There are some additional rules that we must follow--however the compiler enforces these. •Unfortunately, ARC does not protect us from creating retain cycles. 6 Zeroing Weak References The objects in our application can be seen as a directional graph, starting with the UIApplication instance, and moving down through our custom data. Whenever we create a reference to an object (e.g. an object @property in one of our classes), we need to consider whether it refers to a new object, or if it refers back to an object further up in our graph. •If we are referring to a new object, we should use a strong reference. This tells ARC to retain the object for us. •If we are referring back up the graph, we need to use a weak reference. This tells ARC to use a zeroing weak reference. •ARC will not retain the object. It must be retained somewhere else (using a strong reference), or it will not remain in memory. •If the object is ever deallocated, the zeroing weak reference will automatically be set to nil. This eliminates any chance of having dangling pointers. •Objects should always use weak references to their delegates. 7 ARC Rules of the Road •Don’t use objects in C structs. •Don’t create a property with a name that begins with “new.” •Don’t call dealloc, retain, release, retainCount, or autorelease. •Don’t override the retain, release, retainCount, or autorelease methods. •You can override dealloc, but it’s often not necessary. •When implementing dealloc, don’t call [super dealloc]. •Don’t use NSAutoreleasePool objects. Use the new @autoreleasepool{} blocks instead. •Use __bridge __bridge_retain or __bridge_transfer when casting between objects and void*. •Don’t use NSAllocateObject or NSDeallocateObject. •Don’t use memory zones or NSZone. 8 Demo 9 CHAPTER 2 Storyboards Interface Builder (now part of Xcode) has long allowed developers to graphically design their application’s user interface. Even letting developers draw connections between control events and methods in their code. Now, Storyboards takes this one step further. We can not only create an individual scene--we can graphically lay out the relationships and segues between scenes. Interface Builder and Nibs •Unlike many visual tools, Interface Builder does not generate code to create your user interface. Instead, it constructs the interface from live objects, then archives them. •Traditionally, the interface archive is a binary .nib file. When you load a nib, you are loading all the objects that make up the user interface. •Recent versions of Xcode allow saving the interface as XML to better support source control and diff tools. •Modern projects save the files as .xib files, then compile the .xib to a .nib file in the final product. •The terms nib and xib are generally used interchangeably. •Each nib file has a file’s owner. You can draw connections from the owner to objects created by the nib. •IBOutlet allows you to connect instance variables to objects in the nib. •IBAction allows you to connect methods to UIController events in the nib. 11 Nib Demo Storyboards Storyboards extends Interface Builder’s power. While nibs let us define a screenful of information, Storyboards let us graphically lay out the relationships and transitions between screens. •A storyboard has the following features: •One or more scenes. Each scene represents a significant chunk of information on the screen. •Relationships between containers (navigation view controller, tab view controller, etc.) and their content. •Segues between scenes. •At compile time, the storyboard is converted into nib files. •Each scene roughly translates to its own nib file. •There isn’t a strict 1:1 relationship between scenes and nibs. 13 Using Storyboards •Storyboards are only supported by iOS 5 and later. If you want to support earlier versions, you cannot use Storyboards. •You can freely mix Storyboards and nibs inside a single project. However, you must load each new Storyboard or nib in code. A storyboard cannot load a nib or another Storyboard. •One nib can refer to another nib; however, this is not supported in Storyboards. This means we can do some things in nibs that we cannot yet replicate with Storyboards. •You cannot draw connections between the objects of one scene and another. All connections must be drawn within a single scene, with only segues and relationships leading out to other scenes. •Storyboards are most useful when first creating a project: •You can quickly sketch out the framework and workflow for the entire application. •This can save a lot of time when initially setting up the application. 14 Passing Data Across Segues •Before the application segues from one scene to the next, the originating scene’s view controller’s prepareForSegue:sender: method is called. •We should override prepareForSegue:sender: and pass the data we need to the destination’s view controller. •Note: the destination view may not exist yet. We should store the data in the view controller, then pass it to the view in its viewWillAppear: method. •To get data back from the destination, we should make the sending view controller a delegate of the destination. •We must define the delegate protocol ourselves. •We assign the sender as the destination’s delegate in prepareForSegue:sender:.
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]
  • Garbage Collection for Java Distributed Objects
    GARBAGE COLLECTION FOR JAVA DISTRIBUTED OBJECTS by Andrei A. Dãncus A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements of the Degree of Master of Science in Computer Science by ____________________________ Andrei A. Dãncus Date: May 2nd, 2001 Approved: ___________________________________ Dr. David Finkel, Advisor ___________________________________ Dr. Mark L. Claypool, Reader ___________________________________ Dr. Micha Hofri, Head of Department Abstract We present a distributed garbage collection algorithm for Java distributed objects using the object model provided by the Java Support for Distributed Objects (JSDA) object model and using weak references in Java. The algorithm can also be used for any other Java based distributed object models that use the stub-skeleton paradigm. Furthermore, the solution could also be applied to any language that supports weak references as a mean of interaction with the local garbage collector. We also give a formal definition and a proof of correctness for the proposed algorithm. i Acknowledgements I would like to express my gratitude to my advisor Dr. David Finkel, for his encouragement and guidance over the last two years. I also want to thank Dr. Mark Claypool for being the reader of this thesis. Thanks to Radu Teodorescu, co-author of the initial JSDA project, for reviewing portions of the JSDA Parser. ii Table of Contents 1. Introduction……………………………………………………………………………1 2. Background and Related Work………………………………………………………3 2.1 Distributed
    [Show full text]
  • Garbage Collection in Object Oriented Databases Using
    Garbage Collection in Ob ject Or iente d Databas e s Us ing Transactional Cyclic Reference Counting S Ashwin Prasan Roy S Se shadr i Avi Silb erschatz S Sudarshan 1 2 Indian Institute of Technology Bell Lab orator ie s Mumbai India Murray Hill NJ sashwincswi sce du avib elllabscom fprasans e shadr isudarshagcs eiitber netin Intro duction Ob ject or iente d databas e s OODBs unlike relational Ab stract databas e s supp ort the notion of ob ject identity and ob jects can refer to other ob jects via ob ject identi ers Requir ing the programmer to wr ite co de to track Garbage collection i s imp ortant in ob ject ob jects and the ir reference s and to delete ob jects that or iente d databas e s to f ree the programmer are no longer reference d i s error prone and leads to f rom explicitly deallo cating memory In thi s common programming errors such as memory leaks pap er we pre s ent a garbage collection al garbage ob jects that are not referre d to f rom any gor ithm calle d Transactional Cyclic Refer where and havent b een delete d and dangling ref ence Counting TCRC for ob ject or iente d erence s While the s e problems are pre s ent in tradi databas e s The algor ithm i s bas e d on a var i tional programming language s the eect of a memory ant of a reference counting algor ithm pro leak i s limite d to individual runs of programs s ince p os e d for functional programming language s all garbage i s implicitly collecte d when the program The algor ithm keeps track of auxiliary refer terminate s The problem b ecome s more s
    [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]
  • 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]
  • 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]
  • 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]
  • Formal Semantics of Weak References
    Formal Semantics of Weak References Kevin Donnelly J. J. Hallett Assaf Kfoury Department of Computer Science Boston University {kevind,jhallett,kfoury}@cs.bu.edu Abstract of data structures that benefit from weak references are caches, im- Weak references are references that do not prevent the object they plementations of hash-consing, and memotables [3]. In each data point to from being garbage collected. Many realistic languages, structure we may wish to keep a reference to an object but also including Java, SML/NJ, and Haskell to name a few, support weak prevent that object from consuming unnecessary space. That is, we references. However, there is no generally accepted formal seman- would like the object to be garbage collected once it is no longer tics for weak references. Without such a formal semantics it be- reachable from outside the data structure despite the fact that it is comes impossible to formally prove properties of such a language reachable from within the data structure. A weak reference is the and the programs written in it. solution! We give a formal semantics for a calculus called λweak that in- cludes weak references and is derived from Morrisett, Felleisen, Difficulties with weak references. Despite its benefits in practice, and Harper’s λgc. The semantics is used to examine several issues defining formal semantics of weak references has been mostly ig- involving weak references. We use the framework to formalize the nored in the literature, perhaps partly because of their ambiguity semantics for the key/value weak references found in Haskell. Fur- and their different treatments in different programming languages.
    [Show full text]