Data Cache for Intermittent Computing Systems with Non-Volatile Main Memory

Sourav Mohapatra, Vito Kortbeek, Marco Antonio van Eerden, Jochem Broekhoff, Saad Ahmed and Przemyslaw Pawelczak

Tiny devices that run on scavenged energy lose power constantly, so they must checkpoint their state to survive the next blackout; using non-volatile main memory shrinks those checkpoints but forces the device to save far more often to stay correct, and that memory is slow and power-hungry, which begs for a data cache — yet ordinary caches need extra hardware or software just to spot the write-after-read hazards intermittent computing cares about; this paper (TU Delft — Sourav Mohapatra, Przemyslaw Pawelczak, and colleagues) builds NACHO, a cache that folds write-after-read detection into itself so no separate memory tracker is needed, cutting runtime overhead 54 percent against state-of-the-art caches and non-volatile-memory writes 82 percent against a cacheless design.

The argument in one glance

Problem

A device that keeps losing power must save its work, but saving is expensive

Some embedded computers have no battery at all: they scavenge energy from light, radio waves, or vibration into a small capacitor, run until it drains, then die and wait for more. This intermittent operation means power can fail at any instant, so the device must periodically checkpoint its computation state to non-volatile storage; when power returns it resumes from the last checkpoint instead of starting over. The catch is that checkpointing itself costs time and energy, both of which are painfully scarce here. Make the checkpoints big or frequent and the device spends most of its meager power budget just saving state rather than doing useful work. So the whole game of intermittent computing is keeping the computation correct across blackouts while paying as little as possible to do it.
What people did

Make main memory non-volatile so checkpoints shrink

A natural move is to make the main memory itself non-volatile. Then the working data already survives a power failure, so a checkpoint no longer has to copy out the volatile memory, and each checkpoint becomes much smaller. Because the memory persists, the state that used to be the expensive part of a checkpoint is simply there when power returns.
Why it fell short

Non-volatile main memory saves size but costs frequency, speed, and energy

Smaller checkpoints come with three new bills. First, the device now has to checkpoint more often, because a write-after-read dependency through the persistent memory can corrupt a re-execution after a blackout unless the earlier value was saved first. Second, non-volatile memory is much slower to access than volatile memory. Third, it burns more energy per access. The slowness and energy cost cry out for a data cache to absorb the traffic — but ordinary caches are not designed for intermittent computing, and they need extra hardware or software bolted on just to detect the write-after-read hazards that drive the checkpointing.
This paper's idea

Build the write-after-read detector into the cache itself

NACHO is a data cache tailored to intermittent computing that folds write-after-read detection into the cache instead of adding a separate memory tracker. A cache already sees every read and write and already keeps per-line metadata, so it is naturally positioned to notice when a location is written after having been read — exactly the event that forces a checkpoint. By making the cache do that detection as part of its normal operation, NACHO drops the extra hardware or software other systems need, absorbs the slow non-volatile-memory traffic, and reduces both how often the device checkpoints and how much it writes to the persistent memory. The paper reports 54 percent lower runtime overhead than state-of-the-art cache-based systems and 82 percent fewer non-volatile-memory writes than a cacheless design.

Why this problem is worth solving

The reason this is hard is that correctness across a blackout hinges on a subtle ordering hazard.

When a program is re-executed from a checkpoint after a power failure, it repeats the instructions since that checkpoint. If, before the failure, the program read a memory location and then wrote a new value to it, that is a write-after-read dependency. In ordinary computing it is harmless, but with non-volatile memory it is dangerous: the new value persisted through the blackout, so when re-execution reaches the earlier read, it now sees the overwritten value instead of the original one it read the first time. The recomputation diverges from what actually happened, and the result is silently wrong. The standard defense is to make sure a checkpoint captures the original value before such a write is allowed to persist, so that re-execution starts from consistent state. This is why non-volatile main memory, which removes the cost of saving volatile state, paradoxically raises checkpoint frequency: every write-after-read through the persistent memory is a point where the system may have to checkpoint to stay correct. Getting this right cheaply is the crux, because the device has almost no energy to spend and yet cannot afford a single inconsistent re-execution.

And the memory technology that makes checkpoints small is the same one that makes ordinary operation slow.

Non-volatile memory keeps its contents without power, which is exactly what an intermittently powered device needs, but that persistence comes at a price: reading and writing it is significantly slower than volatile memory such as SRAM, and each access consumes more energy. For a device whose entire power budget is a nearly empty capacitor, both costs are severe, and they are paid on every memory access, not just at checkpoints. A data cache is the classic remedy: keep hot data in a small, fast, low-energy store and touch the slow persistent memory only when necessary, which cuts both the latency and the energy of the common case and, as a bonus, reduces the number of writes that reach the wear-sensitive non-volatile memory. But a cache for this setting cannot be a plain performance cache, because the system also needs to know when write-after-read hazards occur so it can checkpoint. That requirement is what has forced prior designs to add a separate hazard tracker alongside the cache, and it is the coupling NACHO sets out to eliminate by making one structure serve both roles.

What people did before, and where it broke

Volatile main memory with full checkpoints. Keep working data in fast volatile memory and, to survive a blackout, checkpoint the whole volatile state to non-volatile storage. Where it broke. The checkpoint must copy out all the volatile memory that matters, making each checkpoint large and expensive in exactly the time and energy the device cannot spare.
Non-volatile main memory to shrink checkpoints. Make the main memory itself persistent so working data survives power loss and checkpoints no longer need to save volatile state. Where it broke. Checkpoint frequency goes up instead, because every write-after-read dependency through the persistent memory is a potential correctness hazard that must be covered by checkpointing, and the persistent memory is slow and energy-hungry on every access.
Software or compiler tracking of write-after-read hazards. Instrument the program, or use compiler passes, to find and guard the write-after-read points that require a checkpoint. Where it broke. The tracking adds runtime work and complexity on a device with essentially no headroom, and it is separate machinery layered on top of memory that already has to be managed.
A conventional data cache plus a separate hazard tracker. Add a standard performance cache to absorb the slow non-volatile-memory traffic, and add extra hardware or software beside it to detect write-after-read dependencies. Where it broke. Existing caches are not built for intermittent computing, and pairing a cache with a distinct memory tracker duplicates state and effort, since the cache already observes the very reads and writes the tracker is trying to watch.
The gap. No data cache for intermittent computing performed write-after-read detection as an intrinsic part of its own operation, so that a single structure both absorbs the persistent-memory traffic and identifies the hazards that trigger checkpoints, without a bolt-on tracker.

How NACHO works

Turning a data cache into the write-after-read detector for intermittent computing

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

The cache already knows what the tracker was trying to learn. The central insight is that a data cache and a write-after-read detector are watching the same thing. Both care about the stream of reads and writes to memory; the cache to decide what to keep and evict, the detector to decide when a checkpoint is required. Prior intermittent-computing designs kept these as separate mechanisms — a cache for performance and a distinct memory tracker for hazards — which duplicates the observation and the state. NACHO collapses them: since the cache is on the path of every access and already maintains metadata per cached line, it is the natural place to notice that a line is being written after it was read, and to raise that as the checkpoint-forcing event. Making one structure serve both the performance role and the correctness role removes the bolt-on tracker entirely. Rethinking a cache so that it takes on a job specific to a new memory technology, rather than staying a generic performance buffer, is the same design instinct the work on re-architecting caches for emerging fast storage covered elsewhere on this site is built on, redesigning the cache around the demands of the memory it fronts instead of reusing an off-the-shelf one.

Non-volatile main memory rebalances the checkpoint bill, and the design must answer the new balance. Choosing persistent main memory is not a free win; it trades one cost for another. It erases the biggest line item — copying volatile state into every checkpoint — but it introduces a new one, because now the correctness of re-execution depends on write-after-read dependencies that live in the persistent memory, and covering them means checkpointing more often. A design that only celebrated the smaller checkpoints while ignoring the higher frequency would come out behind. NACHO is shaped by taking both sides of this trade seriously: it keeps checkpoints small by leaning on persistence, and it attacks the newly-dominant frequency and access costs with the cache. Confronting the specific efficiency-and-correctness tradeoff that a persistence choice forces, rather than assuming persistence is uniformly good, is the same clear-eyed accounting the batteryless energy-harvesting work covered elsewhere on this site brings to intermittent systems, weighing what a device gains against what surviving power failure actually costs it.

Checkpointing is the safety net, so make it cheap enough to trust. Everything here exists to let the device stop and resume across unpredictable blackouts without losing or corrupting work, which is what checkpointing provides — but a safety net that is too expensive to deploy often is no net at all. On a device with almost no energy, the appeal of a scheme is measured by how little it charges to keep state consistent. NACHO’s value is that it lowers the price of correctness on two fronts at once: the cache absorbs the slow persistent-memory accesses that made checkpointing costly, and the in-cache hazard detection removes the separate machinery that made it complex, so the system can afford to checkpoint exactly when a write-after-read actually demands it. Driving down the overhead of persisting state so that reliable recovery is practical rather than prohibitive is the same goal the persistent-checkpointing work covered elsewhere on this site pursues in a very different setting, making the act of saving recoverable state cheap enough that a system can lean on it routinely.

Following a blackout-prone run through NACHO

Staying correct and cheap across a power failure with an integrated cache

An illustrative trace, based on the paper's abstract and established intermittent-computing background, of how NACHO handles reads, writes, and a blackout. The internal mechanism beyond the abstract's description was not available for this draft.

Step 1 of 5

The device runs on harvested energy with data in NVM

An energy-harvesting embedded platform executes a program whose working data lives in non-volatile main memory. A data cache sits between the processor and that memory, serving hot data quickly and cheaply so the slow, energy-hungry persistent memory is accessed only when needed.

Because the main memory is non-volatile, its contents will survive the next blackout, so checkpoints do not need to copy the working data out.

Why it works

One structure does two jobs, so the tracker disappears. A cache and a hazard detector both watch the same reads and writes → but the cache already sits on every access and holds per-line metadata → so folding write-after-read detection into it removes the separate memory tracker other systems require.
The cache absorbs the costs that make NVM painful. Non-volatile memory is slow and energy-hungry on every access → but a cache serves hot data from a small fast store and touches the persistent memory less → so the latency, energy, and write count of ordinary operation all fall.
Detecting hazards for free lets checkpoints be taken only when needed. Covering write-after-read dependencies requires knowing when they occur → but the cache flags them as part of its normal operation → so the device checkpoints exactly at the hazards rather than conservatively or via costly extra tracking.
Fewer writes to non-volatile memory cut energy and wear together. Every store that reaches the persistent memory costs energy and stresses a wear-sensitive medium → but the cache buffers writes and coalesces traffic → so NACHO reports 82 percent fewer NVM writes than a cacheless design and 18 percent fewer than several cache-based ones.
Lower overhead compounds on an energy-starved device. Time and energy spent on checkpointing and slow accesses is time and energy not spent computing → but cutting both the access cost and the tracking complexity reduces that tax → so the reported 54 percent runtime-overhead reduction directly buys more useful work per harvested joule.

What it costs (trade-offs and scope)

This is a draft built from the paper’s abstract. The full paper was behind a publisher access wall for this draft (no preprint on arXiv, no author or repository copy located, and no talk slides available), so this account is assembled from the abstract and established intermittent-computing background. The exact cache organization, how the write-after-read detection is encoded in the cache metadata, the checkpointing protocol, the eviction and consistency policy, the hardware or simulation platform, and the specific baselines are not reproduced here and should be read from the paper.
The reported figures are the abstract’s own, and are comparisons. The 54 percent runtime-overhead reduction is relative to state-of-the-art cache-based systems, the 82 percent fewer non-volatile-memory writes is relative to a cacheless system, and the 18 percent is an average relative to multiple cache-based systems; the exact benchmarks, memory technology, and conditions behind these averages are not detailed in this draft.
A cache adds its own volatile state to reason about. Introducing a cache in front of persistent memory means the cache’s contents and metadata must themselves be handled correctly across a blackout; how NACHO keeps the cache consistent with the non-volatile memory at power failure is central to correctness but is exactly the internal detail the abstract does not spell out.
Benefits depend on access patterns. A cache helps in proportion to locality and to how many write-after-read hazards it can catch and coalesce; workloads with poor locality or unusual dependency patterns may see smaller gains, and the abstract’s averages will not describe every application equally.
Scope is small energy-harvesting embedded platforms. The design targets intermittently powered devices with non-volatile main memory, a specific and constrained class of systems; the ideas do not automatically transfer to general-purpose machines with abundant power and different memory hierarchies.

The evaluation

Handling non-volatile main memory in an intermittently powered device

Property	Cacheless NVM	Cache plus separate tracker	NACHO
Absorbs slow NVM traffic
Write-after-read detection
Extra hardware or software for hazards
NVM writes (per the abstract)
Runtime overhead (per the abstract)

A qualitative comparison based on the paper's abstract; the paper's main body, including its exact cache design, write-after-read detection mechanism, checkpointing protocol, evaluation platform, and specific baselines, was not available for this draft. The 54 percent, 82 percent, and 18 percent figures are the abstract's reported results.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This is an honest draft assembled from the paper’s abstract and standard intermittent-computing background; the full text was not accessible (no arXiv preprint, no author or repository copy found, and the ACM Digital Library version returned a bot-verification challenge), so the internal design is not reproduced. What is solid and comes directly from the abstract: intermittent, energy-harvesting devices must checkpoint frequently; non-volatile main memory shrinks checkpoints but raises checkpoint frequency to cover write-after-read dependencies and is slow and energy-hungry, motivating a data cache; existing caches need extra hardware or software to detect write-after-reads; and NACHO integrates that detection into the cache, dropping the separate tracker. The reported results are 54 percent lower runtime overhead than state-of-the-art cache-based systems, 82 percent fewer non-volatile-memory writes than a cacheless system, and 18 percent fewer on average than several cache-based systems. The explanation of write-after-read hazards and why a cache is well placed to detect them is standard background and the natural reading of the abstract, not a claim about NACHO’s specific internals. Read the exact cache organization, the detection encoding, the checkpointing and consistency protocol, the platform, and the baselines in the paper itself; treat this page as a faithful account at the level of the abstract, not of the implementation.

Background

Why non-volatile memory is a double-edged tool here

It helps to see why persistence is both the cure and part of the disease. An intermittently powered device’s core problem is that power vanishes without warning, so anything it wants to keep across a blackout must live somewhere that does not need power — non-volatile memory. Making the main memory itself non-volatile is therefore deeply appealing, because the working data is automatically safe and the device does not have to copy it out at every checkpoint. But persistence is not free of hazards: the same durability that saves the data also means a value written before a blackout is still there during re-execution, which is precisely what makes write-after-read dependencies dangerous, and the physics of the memory make it slow and power-hungry to touch. So the device must manage this persistent memory carefully — deciding what to write, when, and how to stay consistent — rather than treating it as a passive, always-correct store. That careful management of a non-volatile memory’s writes and metadata, so its persistence is an asset rather than a liability, is the same concern the persistent-memory allocation work covered elsewhere on this site is built around, where handling the metadata of non-volatile memory correctly and cheaply is the whole challenge. NACHO’s cache is, in this light, a way to mediate a device’s relationship with a memory that is wonderful for surviving blackouts but punishing to use naively.

If you remember only three things

1. Intermittently powered, energy-harvesting devices must checkpoint their state to survive constant blackouts; making main memory non-volatile shrinks each checkpoint (no volatile state to save) but raises checkpoint frequency, because write-after-read dependencies through the persistent memory can corrupt a re-execution unless the original value was saved first — and non-volatile memory is slow and energy-hungry on every access, motivating a data cache.
2. The trouble is that ordinary data caches are not built for intermittent computing and need extra hardware or software to detect the write-after-read hazards that drive checkpointing. NACHO's idea is that a cache already observes every read and write and holds per-line metadata, so it is the natural place to detect write-after-reads; by integrating that detection into the cache, NACHO both absorbs the slow persistent-memory traffic and identifies the checkpoint-forcing hazards with a single structure, dropping the separate memory tracker.
3. The paper reports NACHO cutting intermittent-computing runtime overhead by 54 percent versus state-of-the-art cache-based systems, and reducing non-volatile-memory writes by 82 percent versus a cacheless design and 18 percent on average versus several cache-based ones. This explainer is a draft written from the abstract without the paper body, so the exact cache organization, the write-after-read detection encoding, the checkpointing and consistency protocol, the evaluation platform, and the baselines should be confirmed against the paper.

Check yourself

Check your understanding

1. Why does using non-volatile main memory in an intermittent device shrink checkpoints but increase how often the device must checkpoint?
2. What is NACHO's central idea?
3. Why is a data cache especially valuable in front of non-volatile main memory on an energy-harvesting device?
4. What should a reader keep in mind about this particular explainer, and what did the paper report?

Sources

The paper is “Data Cache for Intermittent Computing Systems with Non-Volatile Main Memory” by Sourav Mohapatra, Vito Kortbeek, Marco Antonio van Eerden, Jochem Broekhoff, Saad Ahmed, and Przemyslaw Pawelczak (Delft University of Technology), published at ASPLOS 2025 (Volume 2), DOI 10.1145/3676641.3715989. It is licensed CC BY. The system is named NACHO.

This explainer is a draft. The paper’s main text was not accessible at the time of writing (there is no arXiv preprint, no author or repository copy was located, no talk slides were available, and the ACM Digital Library PDF returned a bot-verification challenge), so it is written from the paper’s abstract together with standard, well-established intermittent-computing background. The abstract supplies the problem framing (intermittently operating energy-harvesting platforms must frequently checkpoint; non-volatile memory reduces checkpoint size by eliminating the need to checkpoint volatile memory but increases checkpoint frequency to cover write-after-read dependencies, and is significantly slower and more energy-hungry to access, suggesting a data cache; existing data caches do not fit intermittent computing and often require additional hardware or software to detect write-after-reads), the core idea (NACHO extends the data cache by integrating it with write-after-read detection, dropping the need for an additional memory tracker), and the reported results (on average 54 percent lower intermittent-computing runtime overhead than state-of-the-art cache-based systems, 82 percent fewer non-volatile-memory writes than a cacheless system, and 18 percent fewer on average than multiple state-of-the-art cache-based systems). The explanation of write-after-read hazards and why a data cache is well placed to observe them is standard intermittent-computing background and the natural reading of the abstract, not a claim about NACHO’s specific internal design. The paper’s exact cache organization, the encoding of write-after-read detection in cache metadata, the checkpointing and cache-consistency protocol, the evaluation platform, and the specific baselines are not reproduced here and should be read from the paper; no numbers beyond the abstract’s have been introduced.