iOS Memory Optimization and Jetsam Mechanism: Reducing OOM Crashes

iOS devices have limited physical memory and no swap space, so the system uses a compressed‑memory approach and a Jetsam mechanism to reclaim memory when pressure arises. When memory becomes scarce, low‑memory notifications are sent to apps, and if they cannot free enough memory, the kernel terminates background processes or even the foreground app, generating a low‑memory report.

The Jetsam implementation resides in the XNU source files kern_memorystatus.h and kern_memorystatus.c. It defines priority buckets (e.g., JETSAM_PRIORITY_BACKGROUND = 3, JETSAM_PRIORITY_FOREGROUND = 10, JETSAM_PRIORITY_HOME = 16) and an array memstat_bucket[MEMSTAT_BUCKET_COUNT] that holds process lists sorted by priority. When memory pressure is detected, the kernel starts one or more high‑priority Jetsam threads (typically priority 95) that repeatedly call memorystatus_action_needed() to decide whether to free memory.

#define MEMSTAT_BUCKET_COUNT (JETSAM_PRIORITY_MAX + 1)

typedef struct memstat_bucket {
    TAILQ_HEAD(, proc) list;
    int count;
} memstat_bucket_t;

memstat_bucket_t memstat_bucket[MEMSTAT_BUCKET_COUNT];

The action loop checks for high‑water OOM (processes exceeding their high‑water mark) and, if none are eligible, proceeds to aggressive reclamation, first killing low‑priority background processes and finally, if necessary, the foreground process (FOOM).

static const char *memorystatus_kill_cause_name[] = {
    "",
    "jettisoned",
    "highwater",
    "vnode-limit",
    "vm-pageshortage",
    "proc-thrashing",
    "fc-thrashing",
    "per-process-limit",
    "disk-space-shortage",
    "idle-exit",
    "zone-map-exhaustion",
    "vm-compressor-thrashing",
    "vm-compressor-space-shortage"
};

Beyond kernel‑level understanding, the article offers concrete app‑level memory‑saving practices: using appropriately sized images, trimming images on the server to match device screen dimensions, promptly releasing image caches, preferring ImageIO‑based scaling over UIImage to avoid intermediate bitmap allocations, employing autorelease pools in tight loops, lazily loading heavy UI components, and rigorously checking for leaks before release.

- (UIImage *)scaleImage:(UIImage *)image newSize:(CGSize)newSize {
    UIGraphicsBeginImageContextWithOptions(newSize, NO, 0);
    [image drawInRect:CGRectMake(0, 0, newSize.width, newSize.height)];
    UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    return newImage;
}

+ (UIImage *)scaledImageWithData:(NSData *)data withSize:(CGSize)size scale:(CGFloat)scale orientation:(UIImageOrientation)orientation {
    CGFloat maxPixelSize = MAX(size.width, size.height);
    CGImageSourceRef sourceRef = CGImageSourceCreateWithData((__bridge CFDataRef)data, nil);
    NSDictionary *options = @{ (id)kCGImageSourceCreateThumbnailFromImageAlways : (id)kCFBooleanTrue,
                               (id)kCGImageSourceThumbnailMaxPixelSize : @(maxPixelSize) };
    CGImageRef imageRef = CGImageSourceCreateThumbnailAtIndex(sourceRef, 0, (CFDictionaryRef)options);
    UIImage *resultImage = [UIImage imageWithCGImage:imageRef scale:scale orientation:orientation];
    CGImageRelease(imageRef);
    CFRelease(sourceRef);
    return resultImage;
}

By applying these strategies, developers can significantly reduce OOM crash rates, keep more apps resident in memory for faster warm‑starts, and maintain a smoother user experience on resource‑constrained mobile devices.