Memory Operating System: Lifecycle & Policy Controls

• Memory Operating System is a framework that treats memory as a managed resource with explicit lifecycle, scheduling, and protection policies.
• It integrates heterogeneous memory types, enabling techniques like page migration, tiering, and metadata-rich control to optimize performance and endurance.
• Recent developments extend Memory OS principles to AI agents by structuring conversational and semantic memory hierarchies for improved model reasoning.

Searching arXiv for recent and foundational papers on "memory operating system" to ground the article in the provided literature and related work. A Memory Operating System denotes an operating-system-level or OS-inspired framework in which memory is treated as an explicitly managed, policy-governed system resource rather than as a passive substrate. Across systems research, this term has been used in at least three closely related senses: OS kernels that manage heterogeneous physical memories such as DRAM, NVM, NVMM, SCM, or LtRAM with explicit placement and migration policies; operating-system mechanisms that restructure protection and access to user memory; and, more recently, memory-centric control planes for LLM agents that organize, retrieve, migrate, and govern multiple forms of computational memory (Salkhordeh et al., 2018, Liu et al., 2017, Li et al., 2022, Kang et al., 30 May 2025, Li et al., 4 Jul 2025, Hu et al., 5 Jan 2026). In all of these senses, the central idea is the same: memory is no longer a flat addressable space or a simple retrieval buffer, but a layered, lifecycle-managed object of allocation, scheduling, migration, protection, consolidation, and reclamation.

1. Historical and conceptual scope

The emergence of hybrid DRAM–NVM systems was an early catalyst for Memory OS thinking. As Non-Volatile Memories entered main-memory hierarchies, several studies argued that traditional OS memory management was inadequate because it did not account for migration cost, power, endurance, and granularity effects. An OS-level hybrid DRAM–NVM memory manager using dual LRU queues was proposed to reduce unnecessary migrations and only allow migrations that benefit the system in terms of power and performance (Salkhordeh et al., 2018). In parallel, the system called memos extended OS control over the entire memory hierarchy, including cache, channels, DRAM, and NVM, using kernel-level monitoring and a page migration engine (Liu et al., 2017).

A second line of work broadened the term beyond mere placement in heterogeneous hardware. In this view, memory management includes privilege separation and control over who may access memory and under what invariants. MProtect argued that unfettered OS access to user memory is not fundamentally necessary for memory management, and introduced a higher-privilege Guardian that mediates access, page-table updates, exceptions, and semantic access through capabilities (Li et al., 2022). This reframes a Memory OS as a system in which memory governance includes confidentiality and integrity, not only placement and latency.

A third line emerged from persistent-memory and SCM research. The analysis of POSIX-compliant operating systems in NVM/SCM environments emphasized that synchronization-related system calls such as poll(), futex(), and wait4() remain dominant overheads even on a RAMdisk, suggesting that simply accelerating the storage substrate does not remove kernel-crossing and metadata bottlenecks (Dubeyko et al., 2017). Related work on terabyte-scale NVMM showed that DRAM-oriented allocators become inadequate when zeroing, compaction, and allocation occur over high-latency, high-capacity media (Garg et al., 2023). This suggests that a Memory OS may require redesigning core physical-memory subsystems rather than merely adding a new tier.

More recent work transferred the Memory OS concept into AI systems. MemoryOS introduced a three-tier conversational memory hierarchy—short-term memory, mid-term memory, and long-term personal memory—along with storage, updating, retrieval, and generation modules (Kang et al., 30 May 2025). MemOS generalized the concept further by unifying plaintext, activation-based, and parameter-level memories under the MemCube abstraction (Li et al., 4 Jul 2025, Li et al., 28 May 2025). EverMemOS then defined a self-organizing lifecycle built around MemCells, MemScenes, and a reconstructive retrieval process oriented toward long-horizon reasoning (Hu et al., 5 Jan 2026). Text2Mem added a formal operation language with schema-validated verbs such as Encode, Retrieve, Delete, Merge, Promote, Demote, Split, Lock, and Expire (Wang et al., 14 Sep 2025).

Taken together, these works show that “Memory Operating System” is not a single architecture but a family of architectures unified by explicit lifecycle control, policy-aware representation, and system-level governance over memory objects.

2. Core design principles

A recurring principle is hierarchical organization. In hybrid hardware systems, the hierarchy typically spans fast DRAM and slower but denser NVM or NVMM, sometimes with cache, channel, and bank placement as additional dimensions (Liu et al., 2017). In LLM-oriented systems, the hierarchy spans short-term, mid-term, and long-term stores (Kang et al., 30 May 2025), or plaintext, activation, and parameter memories (Li et al., 4 Jul 2025, Li et al., 28 May 2025). The underlying premise is that memory tiers differ in latency, capacity, update cost, and persistence, so allocation policy must account for these trade-offs.

A second principle is explicit migration or lifecycle transition. In hybrid DRAM–NVM managers, migrations are triggered by hotness, read/write asymmetry, or inactivity (Salkhordeh et al., 2018, Liu et al., 2017, Shim et al., 18 Jun 2026). In MemOS for AI systems, MemCubes can be promoted, demoted, archived, fused, or parameterized according to usage frequency and semantic stability (Li et al., 4 Jul 2025). EverMemOS formalizes this as a three-phase lifecycle: Episodic Trace Formation, Semantic Consolidation, and Reconstructive Recollection (Hu et al., 5 Jan 2026). Text2Mem makes such transitions first-class operations with explicit invariants (Wang et al., 14 Sep 2025).

A third principle is metadata-rich control. Hardware-oriented systems track hotness, reuse, read/write dominance, dirty bits, lifetime, and contextual ownership (Liu et al., 2017, Kannan et al., 2020). KLOC groups kernel allocations into per-context object maps, where a context is “all kernel objects allocated on behalf of one inode or one socket,” enabling allocation and demotion policies based on active versus inactive contexts (Kannan et al., 2020). AI-oriented systems likewise attach timestamps, provenance, ACLs, TTL, priority, versioning, and usage patterns to MemCubes (Li et al., 4 Jul 2025), or use metadata fields in MemCells for timestamps, source pointers, and origin identifiers (Hu et al., 5 Jan 2026).

A fourth principle is governance and invariants. MProtect enforces two invariants: no OS thread may map or read a sensitive user page in cleartext unless explicitly granted by a capability, and no modification of any page-table frame or interrupt-vector frame is possible without the Guardian’s permission (Li et al., 2022). Text2Mem similarly defines operation-level semantic invariants such as “cannot delete locked” and constrains promote/demote, expire, merge, and lock semantics through validator and parser stages (Wang et al., 14 Sep 2025). This suggests that Memory OS designs increasingly converge on explicit state machines rather than informal heuristics.

A fifth principle is minimization of unnecessary movement and kernel crossings. The dual-LRU hybrid memory scheme avoids blind promotions by using thresholds on read and write counts for only the hottest fraction of the NVM queue (Salkhordeh et al., 2018). The POSIX-on-SCM study argues that preserving POSIX-style system-call sequences can remain fundamentally inefficient, especially due to synchronization-related crossings (Dubeyko et al., 2017). In LLM memory systems, sufficiency-guided retrieval in EverMemOS explicitly seeks only the necessary and sufficient context, avoiding indiscriminate expansion (Hu et al., 5 Jan 2026).

3. OS-level heterogeneous memory management

In hybrid DRAM–NVM operating systems, Memory OS functionality is often expressed through page placement, migration, replacement, and endurance-aware scheduling. One representative design uses two LRU queues, one for DRAM and one for NVM. On a DRAM hit, the page moves to the head of the DRAM-LRU; on an NVM hit, the page moves to the head of the NVM-LRU and may be promoted to DRAM if per-page counters exceed read or write thresholds (Salkhordeh et al., 2018). Counters are maintained only for the top fraction of the NVM queue, with typical parameter choices from PARSEC tuning given as read_window = 5%, R_thresh ≈ 10, write_window = 10%, and W_thresh ≈ 5 (Salkhordeh et al., 2018). The lower write threshold reflects the greater benefit of moving write-dominant hot pages into DRAM.

The cost model in such systems explicitly includes migration. The migration cost per page is modeled as

$$C_{\mathrm{mig}} = t_{r,\mathrm{NVM}} + t_{w,\mathrm{DRAM}}$$

plus DMA overhead, and AMAT includes DRAM hits, NVM hits, misses, and migration terms (Salkhordeh et al., 2018). Power is likewise modeled as a function of DRAM-active accesses, NVM reads and writes, migration-related writes, and static power (Salkhordeh et al., 2018). The point is not merely to keep hot data in fast memory, but to ensure that migration itself does not dominate latency or endurance.

The system memos extends the scope from page migration between DRAM and NVM to full-hierarchy scheduling over LLC, channels, banks, and media types (Liu et al., 2017). Its SysMon module samples PTE access_bit and dirty_bit to infer hotness, read/write dominance, reuse intervals, per-channel and per-bank utilization, and cache-bank associations. It uses W = 8 sampling windows, weight w = 2 on writes, and a last-K = 8 predictor; the paper reports that in 96% of cases this predicts the next T = 10 intervals correctly (Liu et al., 2017). Pages predicted as write-dominant and hot are pinned to DRAM channels, while read-dominant or cold pages are pinned to NVM channels (Liu et al., 2017). This is a memory scheduler in the OS sense rather than a passive NUMA placement heuristic.

KLOC broadens heterogeneous memory management further by showing that kernel objects, not just application pages, are critical tiering targets (Kannan et al., 2020). It characterizes kernel objects such as inodes, dentry cache entries, journal blocks, block-I/O descriptors, and network socket buffers by liveness interval, hotness, and reuse distance. Average lifetimes measured on RocksDB and Redis were 100–200 ms for page-cache pages and 30–80 ms for slab pages such as sk_buff and dentry nodes (Kannan et al., 2020). Because these intervals are short, page-table scans or multisecond sampling windows are too coarse. KLOC therefore allocates all new objects in fast memory for active contexts and demotes pages of inactive contexts in batches using Linux page migration APIs (Kannan et al., 2020). This elevates kernel-internal data structures to first-class managed memory objects within the Memory OS.

A related but more radical redesign appears in Application Read-Only Memory (AROM), which shifts LtRAM management from the DIMM controller into the OS (Shim et al., 18 Jun 2026). AROM enforces the invariant that LtRAM pages are read-only to applications and written only by the OS during page migrations. Application writes to LtRAM trigger copy-on-write faults that migrate the page back to DRAM before the store is applied (Shim et al., 18 Jun 2026). The one-time cost is

$$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$

while wear leveling is handled through an OS token allocator with rate

$r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},$

where $N$ is the number of pages, $E$ is erase endurance, and $T_{\mathrm{lifetime}}$ is target lifespan (Shim et al., 18 Jun 2026). This is a clear instance of a Memory OS in which hardware translation logic is deliberately simplified and responsibility is reassigned to kernel policy.

4. Allocation, virtualization, and protection mechanisms

A Memory Operating System may also be defined by how it restructures the boundary between kernel and process with respect to allocation and translation. The proposal for user-mode memory page allocation argued for eliminating paged virtual memory for anonymous mappings and partially outsourcing page allocation and manipulation into user space (Douglas, 2011). In this design, a process requests, frees, and remaps physical frames in bulk and writes directly into its own page tables under kernel validation. The intended result is O(1) alloc/free up to a threshold of approximately 1 MB, scale-invariant allocation latency for common cases, and instant in-place growth or shrink through remapping rather than copying (Douglas, 2011). This suggests a Memory OS architecture in which page-table manipulation itself becomes part of application-visible memory control.

Another architectural line seeks finer granularity than conventional 4 KB page management. The thesis on simple DRAM and virtual-memory abstractions proposed page overlays, RowClone, Buddy RAM, Gather-Scatter DRAM, and the Dirty-Block Index as complementary mechanisms for sub-page tracking, in-DRAM bulk operations, strided access support, and dirty-state management (Seshadri, 2016). Page overlays extend the virtual-memory framework by allowing each 4 KB virtual page to track a new version of a subset of 64 B cache lines via an Overlay Bit Vector in the TLB (Seshadri, 2016). This directly targets inefficiency from page-granularity operations when only a small sub-page region changes.

Bulk operation support is another important dimension. RowClone performs bulk data copy and initialization entirely inside DRAM, while Buddy RAM enables bulk bitwise operations using DRAM (Seshadri, 2016). These mechanisms matter to a Memory OS because page zeroing, copying, initialization, and remapping are among the dominant costs in large-capacity and heterogeneous memory systems. The study of terabyte-scale NVMM explicitly identifies zeroing as a dominant contributor to allocation cost and calls for zero-fill removal from the fast path, including hardware-accelerated zeroing and coordinated memory management (Garg et al., 2023). A plausible implication is that Memory OS design increasingly depends on joint OS–hardware interfaces for memory operations that were previously treated as simple software loops.

MProtect reinterprets memory management from the protection side. It protects the entire user space of a process using a Guardian running above the OS, with Linux modified only at stable low-level interfaces such as set_pte(), set_ptes(), commit_updates(), copy_from_user(), and copy_to_user() (Li et al., 2022). Sensitive pages are presented to the OS through an encrypted view, with capability-mediated semantic access and secure exception handling (Li et al., 2022). This means that an OS can still manage page tables, handle page faults, scheduling, swapping, and migration while being denied arbitrary cleartext access to user-space memory. In this sense, a Memory OS is not only an allocator or migrator but a mediator of legal memory semantics.

5. Quantitative results and system-level trade-offs

The hybrid DRAM–NVM dual-LRU scheme reported substantial gains on PARSEC when DRAM constituted 10% of the working set and NVM 90%. It reduced power consumption by up to 79% versus DRAM-only memory and by up to 48% versus state-of-the-art CLOCK-DWF, improved AMAT by up to 70% versus CLOCK-DWF, reduced NVM write count by up to 75% versus NVM-only, and by up to 93% versus CLOCK-DWF (Salkhordeh et al., 2018). Representative workloads included canneal, dedup, and streamcluster (Salkhordeh et al., 2018). These figures underscore that migration policy quality can dominate both performance and endurance.

memos reported average throughput gains of 19.1% and average QoS improvement of 23.6% on a hybrid DRAM–NVM system, while reducing NVM-side memory latency by 3~83.3%, energy consumption by 25.1~99%, and improving NVM lifetime by 40X on average (Liu et al., 2017). Its monitoring overhead was reported as < 8%, and page migration cost as 3 μs per 4 KB copy, amortized through lazy batching and DMA (Liu et al., 2017). This demonstrates that OS-level full-hierarchy scheduling can be effective even when monitoring and migration themselves are nontrivial.

KLOC showed that kernel-object tiering leaves “considerable performance on the table” if ignored. On RocksDB, Redis, Cassandra, Spark, and Filebench, it achieved 1.4X to 4X higher throughput compared to prior art (Kannan et al., 2020). More specifically, RocksDB improved by up to 1.4× over migration-only and 2.2× over Nimble; Redis improved by up to 4× over migration-only once network contexts were included; Spark improved by 1.6×–2× for checkpoint phases; and Filebench improved by 1.7× statically and up to 2.5× with readahead hints (Kannan et al., 2020). This indicates that Memory OS policies that ignore filesystem and networking objects are structurally incomplete.

The NVMM study provides the converse result: where conventional OS memory management fails. Median 4 KB allocation on Optane was 33.6 % slower than DRAM in isolated single-thread mode, and under 96 threads median 4 KB allocation slowed by 51× versus DRAM, while 2 MB pages slowed by approximately 39.6× (Garg et al., 2023). Under full fragmentation with only 50 % free memory, serving 2 MB allocations on 1.5 TB Optane drove median allocation latency up by 12 495× and 99th percentile by 11 740× relative to the unfragmented scenario (Garg et al., 2023). By contrast, page freeing remained largely unaffected (Garg et al., 2023). These measurements show that a Memory OS must explicitly differentiate between operations affected by media latency and capacity and those that are not.

AROM’s argument is similarly trade-off oriented. Optane’s hidden translation layer incurs overhead from cache-line granularity mismatch, on-DIMM wear-leveling migrations, address indirection table lookups, and workload-agnostic design (Shim et al., 18 Jun 2026). The OS-driven alternative projects read latencies relative to Optane that are 26–79% faster, depending on the LtRAM technology, while using page-granularity writes and OS-scheduled erases (Shim et al., 18 Jun 2026). Here the trade-off is between hardware complexity and OS responsibility.

The following table summarizes several representative quantitative claims.

System	Reported benefit	Scope
Dual-LRU hybrid DRAM–NVM (Salkhordeh et al., 2018)	up to 79% power reduction vs. DRAM-only	PARSEC, DRAM=10% working set
memos (Liu et al., 2017)	19.1% average throughput gain	full hierarchy: cache, channel, DRAM, NVM
KLOC (Kannan et al., 2020)	1.4X to 4X higher throughput	kernel objects in tiered memory
NVMM allocator analysis (Garg et al., 2023)	51× median slowdown for 4 KB allocation under 96 threads	Linux buddy allocator on Optane
AROM (Shim et al., 18 Jun 2026)	26–79% faster reads relative to Optane	OS-managed LtRAM interface

These results do not define a single best design. Instead, they show that the success of a Memory OS depends on which memory objects are visible to policy, how migration and zeroing are managed, and where the hardware–software boundary is drawn.

6. Memory Operating Systems for AI agents

In LLM systems, the phrase “Memory Operating System” has been used to denote a control plane that manages heterogeneous machine memory representations with explicit lifecycle, scheduling, and governance. MemoryOS defines three storage tiers: short-term memory as a queue of dialogue pages, mid-term memory as segments of related pages, and long-term personal memory as persistent user and agent persona stores (Kang et al., 30 May 2025). Short-term to mid-term updates follow a dialogue-chain-based FIFO principle, while mid-term to long-term updates use segmented page organization and a heat score

$$Heat(s)=\alpha N_{\mathrm{visit}(s)}+\beta L_{\mathrm{interaction}(s)}+\gamma R_{\mathrm{recency}(s)},$$

with

$$R_{\mathrm{recency}(s)}=\exp\!\Bigl(-\frac{\Delta t}{\mu}\Bigr)$$

(Kang et al., 30 May 2025). Segments with $Heat(s)\ge\tau$ are promoted to long-term personal memory (Kang et al., 30 May 2025).

MemOS broadens the ontology of memory types beyond conversational transcripts. It defines plaintext memory, activation memory, and parameter memory, all exposed through the MemCube abstraction

$\text{MemCube}=(P,M),$

where $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$0 is the payload and $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$1 stores identifiers, timestamps, origin, type, ACL, TTL, priority, provenance, version chain, and usage statistics (Li et al., 4 Jul 2025). It introduces policy-aware transitions such as promotion from plaintext to activation on hotness and fusion into parameter memory on sufficient semantic stability. The transition function is written as

$$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$2

where $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$3 is usage frequency and $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$4 semantic stability (Li et al., 4 Jul 2025). This is strongly analogous to OS tiering and eviction, but over semantic objects rather than physical pages.

EverMemOS uses a different abstraction vocabulary centered on MemCells and MemScenes (Hu et al., 5 Jan 2026). A MemCell is defined as

$$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$5

where $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$6 is an episodic narrative, $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$7 is a set of atomic facts, $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$8 is a set of Foresight signals with validity intervals, and $$T_{\mathrm{migrate}} = T_{\mathrm{read}}^{\mathrm{LtRAM}} + T_{\mathrm{write}}^{\mathrm{DRAM}},$$9 is metadata (Hu et al., 5 Jan 2026). MemScenes aggregate related MemCells and maintain a centroid embedding, LLM-generated summary, and scene-specific user profile updates (Hu et al., 5 Jan 2026). Retrieval proceeds through dense and sparse scoring, Reciprocal Rank Fusion,

$r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},$0

scene selection, candidate pooling, and an LLM sufficiency checker that recursively issues follow-up queries if context is insufficient (Hu et al., 5 Jan 2026). This is a memory manager whose analogues to allocation, compaction, paging, and garbage collection are made explicit by the authors.

Text2Mem contributes a formal operation layer for Memory OS backends (Wang et al., 14 Sep 2025). It defines a JSON-schema-governed verb set—Encode, Retrieve, Delete, Merge, Promote, Demote, Split, Lock, Expire—validated by structural and semantic invariants and then mapped to typed operation objects and backend adapters (Wang et al., 14 Sep 2025). Operations are modeled as functions over a memory state $r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},$1, with atomicity and lifecycle semantics. For example, deletion requires $r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},$2, soft deletion maps status to "deleted", and hard deletion maps $r = \frac{N \cdot E}{T_{\mathrm{lifetime}}},$3 (Wang et al., 14 Sep 2025). This suggests a maturation from heuristic memory frameworks to formally specified, executable Memory OS interfaces.

Empirically, these AI systems report benchmark gains. MemoryOS reported on LoCoMo an average improvement of 49.11% on F1 and 46.18% on BLEU-1 over the baselines on GPT-4o-mini (Kang et al., 30 May 2025). EverMemOS reported 86.76% overall accuracy on LoCoMo versus Zep’s 81.06%, 83.00% overall on LongMemEval versus MemOS’s 77.80%, and 53.25% on PersonaMem v2 versus the best baseline MemOS at 50.72% (Hu et al., 5 Jan 2026). MemOS reported on LOCOMO that MemOS-0630 outperformed baselines including LangMem, Zep, OpenAI-Memory, and Mem0, with overall LLM-Judge score approximately 73.31±0.05, and that KV injection reduced Time-to-First-Token by 60–94 % while preserving identical outputs (Li et al., 4 Jul 2025). These results indicate that the Memory OS abstraction is not merely metaphorical in AI systems; it is directly tied to memory representation, retrieval latency, and reasoning performance.

7. Limitations, debates, and future directions

One recurring debate concerns whether existing abstractions can simply be adapted or whether they must be replaced. In SCM research, the conclusion was pessimistic about preserving POSIX as-is: OS and metadata system calls are important optimization targets, but synchronization-related calls remain dominant and are not eliminated even by RAMdisk platforms (Dubeyko et al., 2017). This suggests that a Memory OS for persistent memory may require user-space metadata, direct load/store APIs, or library-OS designs rather than incremental POSIX tuning.

A second debate concerns where control should reside: in hardware, the kernel, user space, or an external monitor. AROM explicitly moves wear leveling and write-granularity management from the DIMM controller to the OS (Shim et al., 18 Jun 2026). User-mode page allocation moves some page management from the kernel to the process (Douglas, 2011). MProtect moves sensitive mediation above the OS into the Guardian (Li et al., 2022). These designs are not interchangeable; they embody different trust models, overhead structures, and implementation constraints.

A third debate concerns how broad the unit of management should be. Many early systems manage pages, but KLOC argues that kernel objects must also be first-class citizens (Kannan et al., 2020). MemOS and EverMemOS go further still, treating semantically structured objects with provenance, summaries, and version chains as memory units (Li et al., 4 Jul 2025, Hu et al., 5 Jan 2026). This suggests a general trend from fixed-size blocks toward richer memory objects whose identity is defined by semantics and lifecycle rather than address alone.

Several limitations recur across the literature. In hardware-tiered systems, excessive migration burns NVM write cycles, blind promotion can dominate AMAT, and large-scale compaction becomes prohibitive on NVMM (Salkhordeh et al., 2018, Garg et al., 2023). In protection-oriented systems, mediation on every context switch, page fault, and syscall introduces ~2–5 μs per-event overhead, and software cryptography dominates cold-start costs (Li et al., 2022). In AI-oriented Memory OS frameworks, multiple LLM calls for segmentation, consolidation, and sufficiency checking add latency and cost, while benchmark coverage remains incomplete for profile stability and foresight (Hu et al., 5 Jan 2026). Text2Mem itself outlines Text2Mem Bench as a planned benchmark, indicating that standardized evaluation remains an open problem (Wang et al., 14 Sep 2025).

Future directions follow naturally from these tensions. The NVMM literature calls for zeroing elimination, latency-aware allocators, persistence-aware page-table placement, fragmentation avoidance, and coordinated memory-management subsystems (Garg et al., 2023). The Memory OS literature for AI systems points toward cross-platform memory portability, memory interchange protocols, decentralized memory marketplaces, self-optimizing memory units, multimodal extension, and formalized operation languages (Li et al., 4 Jul 2025, Li et al., 28 May 2025, Wang et al., 14 Sep 2025). A plausible implication is that the term “Memory Operating System” will continue to converge around a common pattern: memory represented as typed objects with lifecycle state, explicit governance, migration policies, and programmable operations, whether the substrate is DRAM/NVMM hardware or the heterogeneous internal and external memory of an AI agent.