Final Follow-Up Post

February 09, 2023

Back Again

Diving into memory management turned out to be a longer trip than anticipated. It's reminiscent of Gendry's rowing in Game of Thrones - what was meant to be a brief stint turned into a prolonged saga. Similarly, our exploration into the XOR linked list in Swift led us down the winding river of Objective-C's memory management.

Our initial aim with the XOR linked list in Swift was straightforward. But, as often happens, things got complicated. Diving into Objective-C's memory management wasn't a whimsical choice; it was necessary.

This time, we're going to plan out what we're going over. This'll make sure we aren't just drifting around anymore. Here's an outline that ties topics to building construction:

  • Foundation: The basics of memory management with DisguisedPtr and ObjcAssociation.
  • Framework: The structural aspects with AssociationsManager and AssociationsHashMap.
  • Interior Design: The complexities introduced by Tagged Pointer Objects.
  • Safety Measures: Ensuring stability with Weak References in Objective-C.
  • Renovation: Adapting and applying insights to the XOR Linked List in Swift.


DisguisedPtr and ObjcAssociation

Every building starts with a foundation. In memory management, that's DisguisedPtr and ObjcAssociation.


  • What It Does: Inhibits heap tracing.
  • How It Works: DisguisedPtr masks the actual pointer value, preventing tools that trace heap memory from accessing the real object pointer.
  • What Does This Mean: Think of it as a protective cloak for your pointers. It hides them from prying eyes, ensuring they're safe from unintended interference.
  • Why It Matters: This masking ensures that memory operations don't mistakenly access or modify the object, maintaining integrity.


  • What It Does: Manages associations between objects.
  • How It Works: It employs hash maps and policies. When associating one object with another, it's stored in a hash map with a specific policy defining the association type (strong, weak, etc.).
  • What Does This Mean: It's like a filing system for relationships. Each object gets a "file" with clear rules on how it relates to others.
  • Why It Matters: This approach ensures clear rules for object relationships, setting boundaries and ensuring each association serves its purpose.

Together, these components provide the bedrock for our memory management system.


AssociationsManager and AssociationsHashMap

In construction, a framework gives a building its shape and stability. In memory management, AssociationsManager and AssociationsHashMap provide that structural backbone, organizing and managing object associations.


  • What It Does: Manages locks for object associations.
  • How It Works: It ensures that when associations are being read or modified, they're done so in a thread-safe manner. This is achieved by implementing locks that prevent simultaneous access, avoiding potential conflicts or data corruption.
  • What Does This Mean: Think of it as a security guard regulating access to a VIP area. Only one person (or thread) is allowed in at a time, ensuring no chaos ensues.
  • Why It Matters: In a multithreaded environment, ensuring thread safety is paramount. AssociationsManager ensures that object associations remain consistent and free from race conditions.


  • What It Does: Stores object associations.
  • How It Works: It uses a hash map, a data structure that allows for efficient storage and retrieval of object associations based on keys.
  • What Does This Mean: Imagine a vast storage warehouse where each item (object association) has a unique barcode (key). You can quickly find and retrieve any item based on its barcode.
  • Why It Matters: Efficient storage and retrieval of object associations are crucial for performance. AssociationsHashMap ensures that this process is both fast and reliable.

The framework ensures object associations are stored effectively and accessed without issues.

Interior Design

Tagged Pointer Objects

The interior design of a building adds character and functionality. In memory management, Tagged Pointer Objects introduce a layer of complexity and nuance.

Tagged Pointer Objects

  • What It Does: Provides a mechanism for storing small objects.
  • How It Works: Instead of using a full pointer to reference an object, the pointer itself is used to store the object's data for small objects. This is a space-saving technique.
  • What Does This Mean: Imagine a compact storage unit where items are stored within the walls or structure itself, rather than taking up additional space.
  • Why It Matters: It's an optimization. By using tagged pointers, memory usage is reduced, leading to more efficient memory management.

However, there are implications:

  • Setting an Associated Object: When you set an associated object on a tagged pointer object, it can change its nature, potentially converting it from a tagged pointer to a regular pointer.
  • Permanence in the Associations Hash Map: Once a tagged pointer object has an associated object, it remains in the associations hash map, even if the association is later removed.

Getting a handle on Tagged Pointer Objects is important because they directly influence memory efficiency.

Safety Measures

Weak References in Objective-C

In construction, safety measures prevent disasters. In memory management, weak references in Objective-C serve a similar protective role.

Weak References in Objective-C:

  • What It Does: Allows references to objects without preventing those objects from being deallocated.
  • How It Works: When the only reference to an object is a weak reference, the object can be deallocated and the reference is automatically set to nil.
  • What Does This Mean: Think of it as a safety rope that detaches itself if the object it's tied to is removed, ensuring no dangling references.
  • Why It Matters: It prevents memory leaks and ensures that references don't point to deallocated memory, which could lead to crashes.

A specific behavior to note:

  • OBJC_ASSOCIATION_ASSIGN Policy: This policy is like a weak reference, but with a twist. It doesn't set the reference to nil when the object it points to is deallocated. This can lead to dangling pointers if not handled carefully.

Comparison with Swift's References:

  • unowned in Swift: OBJC_ASSOCIATION_ASSIGN is somewhat similar to unowned in Swift. Both don't nil out the reference when the object is deallocated. However, unowned in Swift is explicitly non-optional and will trigger a runtime crash if accessed after its object has been deallocated, whereas OBJC_ASSOCIATION_ASSIGN can lead to unpredictable behavior without an immediate crash.
  • weak References in Swift: Swift's weak references are always nilled out when the object they point to is deallocated, offering a safer approach and reducing the risk of dangling pointers.


#import <Foundation/Foundation.h>

 A node structure for the XOR linked list.
 @field value The integer value stored in the node.
 @field both The XOR combination of the addresses of the previous and next nodes.
typedef struct Node {
    int value;
    struct Node *both;
} Node;

 An Objective-C implementation of an XOR linked list.
 This data structure uses XOR operations to save space for previous and next pointers in doubly linked lists.
@interface XORLinkedList : NSObject {
    Node *head;  // The first node in the list.
    Node *tail;  // The last node in the list.

 Adds an element to the end of the list.
 @param element The integer value to be added.
- (void)add:(int)element;

 Retrieves the value at a specific index in the list.
 @param index The index of the desired value.
 @return The value at the specified index or nil if the index is out of bounds.
- (NSNumber*)get:(int)index;


@implementation XORLinkedList

 Initializes a new XOR linked list.
 @return An initialized XOR linked list.
- (instancetype)init {
    self = [super init];
    if (self) {
        head = NULL;
        tail = NULL;
    return self;

 A helper function to compute the XOR of two node pointers.
 @param a The first node pointer.
 @param b The second node pointer.
 @return The XOR of the two node pointers.
static Node* xor(Node *a, Node *b) {
    return (Node*)((uintptr_t)a ^ (uintptr_t)b);

 Adds an element to the end of the list.
 This method creates a new node and appends it to the end of the XOR linked list.
 If memory allocation for the new node fails, an error message is logged, and the method returns without adding the node.
 @param element The integer value to be added.
- (void)add:(int)element {
    Node *newNode = malloc(sizeof(Node));
    // Check if memory allocation was successful.
    if (!newNode) {
        NSLog(@"Failed to allocate memory for new node.");
    newNode->value = element;
    newNode->both = xor(tail, NULL);  // Since it's the last node, XOR with NULL.

    if (!head) {
        head = newNode;
        tail = newNode;
    } else {
        tail->both = xor(tail->both, newNode);  // Update the XOR value of the previous tail.
        tail = newNode;  // Set the new node as the tail.

- (NSNumber*)get:(int)index {
    if (index < 0) return nil;  // Negative indices are invalid.

    if (!head) return nil;  // List is empty.

    Node *prev = NULL;
    Node *current = head;
    for (int i = 0; i < index; i++) {
        if (!current) return nil;  // Index is out of bounds.
        Node *next = xor(prev, current->both);
        prev = current;
        current = next;

    if (current) {
        return [NSNumber numberWithInt:current->value];
    } else {
        return nil;

 Deallocates the memory used by the XOR linked list.
- (void)dealloc {
    Node *prev = NULL;
    Node *current = head;
    while (current) {
        Node *next = xor(prev, current->both);
        prev = current;
        free(current);  // Free the memory of the current node.
        current = next;


int main(int argc, const char * argv[]) {
    @autoreleasepool {
        XORLinkedList *xorLinkedList = [[XORLinkedList alloc] init];

        [xorLinkedList add:1];
        [xorLinkedList add:2];
        [xorLinkedList add:3];
        [xorLinkedList add:4];

        NSLog(@"%@", [xorLinkedList get:0] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:1] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:2] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:3] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:4] ?: @"nil");

        [xorLinkedList add:5];
        [xorLinkedList add:6];

        NSLog(@"%@", [xorLinkedList get:4] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:5] ?: @"nil");
        NSLog(@"%@", [xorLinkedList get:6] ?: @"nil");
    return 0;