If you have ever had an app vanish without warning, or seen the spinning beachball freeze your Mac during an intensive task, jetsam was probably involved. It operates deep inside the XNU kernel, out of sight, making hard decisions about which processes to terminate when available memory gets dangerously thin. Understanding what it does helps make sense of several puzzling behaviours that Mac users often blame on bugs, crashes, or bad software.
Jetsam is not new. It was built for iOS, where RAM constraints are severe and there is no swap space to fall back on. Apple ported it to macOS as the two platforms converged, and it now runs on every Mac regardless of chip or macOS version. Most of the time it runs quietly and you never notice. When you do notice, it usually means the system is genuinely under pressure.
What jetsam actually is
Jetsam is Apple's implementation of an out-of-memory (OOM) killer for the XNU kernel. The name comes from maritime terminology: jetsam is cargo thrown overboard to keep a ship from sinking. The analogy is apt. When the memory pressure on a Mac or iPhone becomes unsustainable, jetsam jettisons processes to keep the kernel itself stable.
Before jetsam existed on mobile, iOS handled memory pressure with a simpler signal-based approach: the kernel would send memory warnings to apps, apps would hopefully free some memory in response, and if they did not, things would eventually crash. Jetsam replaced that reactive pattern with a proactive, priority-ordered termination system. Apple later brought this same system to macOS, where it complements the existing swap mechanism.
On macOS, jetsam works alongside virtual memory and swap. The Mac can move inactive pages to disk to buy time, whereas iOS historically could not. But swap has limits: it is slower than RAM, and on Apple Silicon Macs it uses SSD storage that has finite write endurance. When swap is exhausted or too slow to help, jetsam is the last line of defence before a kernel panic. As Jonathan Levin's detailed work on macOS and iOS internals documents, jetsam is deeply embedded in the kernel's memory management architecture, not a superficial layer on top of it.
How jetsam decides what to kill
Jetsam does not pick processes randomly. It uses a priority band system that ranks every running process based on its current state and importance to the user. Processes in lower-priority bands are killed first; processes in higher-priority bands are protected until the situation becomes truly critical.
The broad hierarchy works like this:
- Suspended background apps are killed first. These are apps you opened earlier that are no longer active but still occupy memory. iOS suspends apps aggressively; macOS is more lenient, but background processes are still low on the priority list.
- Background apps come next. An app running a background task, like syncing or downloading, sits above suspended apps but well below anything the user is actively looking at.
- Foreground apps are protected until things are severe. The app you are currently using is the last thing jetsam wants to kill, because terminating it is immediately visible and disruptive.
- System services and the kernel are off-limits. Jetsam will not touch the processes that macOS itself depends on to function.
Within each band, memory consumption matters. A background process using 2 GB is a more attractive target than a background process using 50 MB. Jetsam weighs both factors, making it a considerably more thoughtful mechanism than simply killing the largest process in the list.
The "system has run out of application memory" connection
You may have seen a macOS dialogue that reads "Your system has run out of application memory." This alert is the user-facing side of what jetsam is managing underneath. When macOS runs out of application memory, it is not simply that RAM is full: the kernel has exhausted the memory it can make available through a combination of RAM, swap, and background-process eviction, and it can no longer satisfy allocation requests from the apps you are running.
The dialogue appears because the system reached a state where even jetsam's evictions were not sufficient to restore headroom. Apps listed in the dialogue are the ones macOS is asking you to quit manually, because it has either already terminated the processes it could safely kill automatically, or the remaining processes are too important to terminate without your input.
Not every jetsam event produces a visible alert. Most of the time, jetsam quietly terminates a background process, memory pressure eases, and nothing obvious happens. You might notice that an app you had open in the background needs to reload when you switch back to it; that is a sign it was terminated and restarted silently. The alert only appears when the situation has escalated beyond what silent termination can resolve. If you want to understand how to respond when it does appear, the guide to fixing the out-of-application-memory error walks through the options step by step.
Why iOS sees jetsam more than macOS
If you have ever noticed that iPhone apps frequently need to reload when you switch back to them, that is jetsam at work, and it is far more aggressive on iOS than macOS for several reasons.
First, iOS devices have less RAM than most Macs. An iPhone might have 6 GB or 8 GB; a Mac typically has 8 GB to 36 GB or more. The headroom is simply tighter on iOS, so jetsam reaches for the kill switch sooner.
Second, iOS historically had no swap space at all. Early iPhones and iPads could not offload inactive memory to storage the way macOS does. This meant jetsam was the only tool available once RAM filled up. More recent versions of iOS introduced a limited form of memory compression, but iOS still does not swap to disk the way macOS does.
Third, the iOS app-suspension model is built around the assumption that apps will be terminated. iOS freezes background apps and expects developers to save state so they can restore it quickly after a jetsam kill. macOS apps have historically been allowed to run more freely in the background, which makes jetsam's job harder: terminating a background macOS process may leave work unsaved in ways that terminating a suspended iOS app would not.
The practical result is that memory pressure on iOS tips into jetsam territory more quickly, more frequently, and more visibly than on macOS. On a Mac, the swap file and the larger RAM budget give jetsam more time and space before it needs to act.
What jetsam tells you when it kicks in
When jetsam starts terminating processes visibly, it is telling you something concrete: you have hit the wall. The system has used its RAM, filled its swap, and is now forcibly evicting processes to survive. That is not a warning sign or a yellow flag; it is a red one.
The most useful thing to understand is that jetsam acts on the current state of memory, not on what caused the situation. It does not know or care whether you have a memory leak in one app, too many browser tabs open, or simply more apps running than your Mac's RAM can comfortably support. It only knows that memory is critically low and it needs to free some immediately.
If jetsam is killing apps regularly, the practical responses are the same regardless of the root cause:
- Quit apps and browser tabs you are not actively using. Fewer processes means less demand on RAM and less work for jetsam to do.
- Identify memory hogs in Activity Monitor. Sort by memory use and look for processes consuming far more than expected. A browser with dozens of tabs, an app with a memory leak, or a runaway background helper can all push the system towards jetsam territory.
- Restart your Mac. A restart clears swap, frees leaked memory, and gives jetsam a clean slate to work from.
- Consider whether your RAM is sufficient for your workflow. If jetsam kills are a frequent occurrence, your typical workload may genuinely exceed your Mac's memory capacity.
Jetsam's logs are written to the system log and can be read with the Console app or the log command-line tool. Entries tagged with memorystatus or jetsam show which processes were terminated, when, and from which priority band. Reading these logs can help you understand exactly which apps are getting killed and how often, which is useful if you are trying to diagnose a recurring problem.
The underlying goal is to get ahead of jetsam rather than react to it. Once jetsam is active, you are already at the point where the kernel is making decisions for you. Keeping memory pressure in the green or yellow range is the way to ensure those decisions never need to be made.