---
title: Memory Segregation in Modern Systems
url: https://www.emergentmind.com/topics/memory-segregation
type: topic
---

# Memory Segregation in Modern Systems

Searching arXiv for the cited works to ground the article in current paper metadata.
Memory segregation denotes the partitioning of memory into regions, domains, or classes with distinct access, placement, lifetime, or management properties. Across the literature, the term appears in several technically different but structurally related senses: hardware-enforced isolation of virtual machines in physical memory [1503.03169], segregation of hot and cold objects in the virtual address space for memory tiering [2510.19765], coordinated partitioning of cache and DRAM resources across the hierarchy [1704.01198], region-based language mechanisms for statically separated allocation and deallocation [2506.02182], separation of allocator metadata from user heap data [2410.17928], and least-privilege control over mappings in heterogeneous address-translation networks [1908.08707], [2009.02737]. In each case, the common idea is that memory is not treated as a single undifferentiated pool: instead, boundaries are introduced so that access, placement, reclamation, or authority can be controlled more precisely.

## 1. Hardware-enforced isolation domains

In virtualization, memory segregation is presented as the creation of “true isolated physical memory region[s]” for each virtual machine, such that each VM has a region that is “unobservable and unmodifiable by other VMs or by a compromised hypervisor” [1503.03169]. The ASMI architecture realizes this by dividing physical memory into fixed-size segments, associating each segment with exactly one VM or the hypervisor, and placing a hardware unit, **Pro-mem**, between the paging unit and DRAM [1503.03169]. Pro-mem maintains a per-processor **VMIDR** register, a hardware-managed **Memory Protection Table (MPT)** with entries of the form $(\text{SegID}, \text{VMID})$, and dynamic-partitioning quantities including $\text{TSEG}$, $\text{TOT}$, and $\text{MSEG}$ [1503.03169].

The access rule is hardware-level and per access. If a physical address $a$ lies in segment $s$, with $\text{MPT}[s] = \text{VMID}_s$, and the current VM identifier is $\text{VMID}_c$, then access is allowed iff $\text{VMID}_c = \text{VMID}_s$ [1503.03169]. The same paper states that a compromised hypervisor cannot modify the MPT, cannot directly change VMIDR, and cannot bypass Pro-mem, because Pro-mem sits between paging and DRAM [1503.03169]. ASMI therefore treats the hypervisor as another VM-like principal rather than as a universally trusted memory manager.

A related but distinct hardware view appears in least-privilege memory protection for heterogeneous systems. There, memory segregation is formulated over a configurable network of address spaces rather than a single physical address space [1908.08707], [2009.02737]. Translation structures, IOMMUs, device-local MMUs, and other units are modeled as part of the protection substrate, and authority is split between **Grant** rights over memory objects and **Map** rights over address spaces or translation structures [1908.08707]. The 2020 extension makes the same point in reference-monitor terms: CPUs, DMA-capable devices, accelerators, and co-processors must all be covered by a system-wide memory protection model because many accesses do not pass through the CPU MMU alone [2009.02737]. This suggests that, in modern hardware, memory segregation increasingly concerns not just data regions but also control over the translation paths that reach them.

## 2. Segregation by access temperature and tiering behavior

A second major meaning of memory segregation is the separation of **hot** and **cold** data so that page-based reclamation and tiering can act on more uniform regions. “Tidying Up the Address Space” defines **hotness fragmentation** as the intermingling of hot and cold objects within the same physical or virtual pages, and introduces **address-space engineering** as “dynamically reorganizing an application’s virtual address space to create uniformly hot and uniformly cold regions” [2510.19765]. The paper formalizes the issue with **Page Utilization**:
\[
\text{PageUtilization}(T)=\frac{\text{TotalUniqueBytes}(T)}{\text{UniquePages}(T)\times \text{PageSize}}
\]
and uses this as the central measure of whether page-level policies align with object-level hotness [2510.19765].

The concrete system, **HADES**, implements this form of segregation through three heaps—**NEW**, **HOT**, and **COLD**—managed by a compiler/runtime frontend that tracks object hotness and migrates objects accordingly [2510.19765]. The HOT heap is placed on huge pages; the COLD heap is marked with `MADV_COLD` and, when promotion rate stabilizes below target, with `MADV_PAGEOUT`; the NEW heap holds unclassified objects [2510.19765]. Tracking uses tagged pointers, an access bit, and an **Active Thread Count (ATC)** embedded in guide bits, with an epoch-based migration protocol that moves objects only when $\text{ATC}=0$ [2510.19765]. The design is explicitly a frontend/backend decomposition: the frontend is object-aware and constructs tiering-friendly regions, while the backend remains page-based and unmodified [2510.19765].

The evaluation shows that initial Page Utilization is approximately 18–20% and improves by about $2\times$ for workload A, $3\times$ for workload B, and $4\times$ for workload C, reaching up to about 80% [2510.19765]. For CrestDB with 10 pointer-based data structures, HADES reports up to **70%** memory reduction, approximately **2.5%** average throughput reduction, and approximately **5%** latency increase [2510.19765]. The same work describes a **promotion rate** metric and an **MIAD (Multiplicative Increase, Additive Decrease)** policy to control demotion aggressiveness, initially using `MADV_COLD` and later switching to `MADV_PAGEOUT` when conditions stabilize [2510.19765]. A plausible implication is that, in this line of work, segregation is valuable not because it prevents unauthorized access, but because it restores semantic alignment between object temperature and page-level management.

## 3. Segregation across the memory hierarchy and the address-space graph

The phrase also denotes controlled separation of resources across multiple levels of the hierarchy. “Tackling Diversity and Heterogeneity by Vertical Memory Management” introduces **vertical partitioning**, where the OS uses address bits that influence LLC sets, DRAM banks, and related structures to assign applications coordinated “vertical slices” of the hierarchy [1704.01198]. The paper distinguishes **B-bits** (bank-only), **C-bits** (cache-only), and **O-bits** (overlapped bits affecting both LLC and DRAM), and uses page coloring over these bits so that each application receives a partition that spans LLC and DRAM simultaneously [1704.01198]. The framework combines vertical and horizontal policies through a data-mined policy decision tree and reports **up to 11% performance gains** over unmodified Linux and prior bank partitioning techniques [1704.01198].

Segregation in disaggregated and far-memory systems appears in another address-space form. “Collective Allocator Abstraction to Control Object Spatial Locality in C++” models the virtual address space as two subspaces: a **purely-local region** that is never swapped and a **swappable region** divided into fixed-size pages [2403.02183]. The **collective allocator** organizes multiple **sub-allocators**, each owning a distinct subspace, and exposes methods such as `get_suballocator(kind)`, `get_suballocator(ptr)`, `if_suballocator_contains`, and `is_occupancy_under(r)` [2403.02183]. This lets container code place shallow or hot nodes in the purely-local region and collocate related nodes within the same swappable page [2403.02183]. The paper reports that B-tree and skip-list implementations with the combined use of purely-local-aware and page-aware placement required only modest code changes, and that the modified implementations had data layouts suppressing swapping [2403.02183].

At a broader architectural level, least-privilege work on heterogeneous hardware models the machine as a graph of address spaces and translation units [1908.08707], [2009.02737]. The 2019 paper explicitly separates **Map** from **Grant** rights and represents objects such as `RAM`, `Frame`, and `TStructure`, with an invariant that unmappable objects are never directly accessible [1908.08707]. The 2020 paper extends this to a “system-wide reference monitor for memory” that includes IOMMUs, device-local MMUs, firewalls, and memory controllers [2009.02737]. In this sense, memory segregation concerns which principal may access which object and which principal may reconfigure the address spaces that expose those objects.

## 4. Kernel, process, and heap-level protection domains

In operating systems and runtimes, memory segregation often means creating multiple protection domains inside what is otherwise a shared address space. “Divide et Impera: MemoryRanger Runs Drivers in Isolated Kernel Spaces” applies this idea to Windows kernel-mode drivers using Intel VT-x and EPT [1812.09920]. MemoryRanger creates a **Default EPT** plus one EPT per isolated driver, with each driver running in a separate kernel enclave. The policy distinguishes driver code, driver data, dynamically allocated pools, and OS internal structures such as `EPROCESS` regions [1812.09920]. When a driver is scheduled, an execute EPT violation in the Default EPT triggers a switch to that driver’s EPT; when control returns to the kernel or another driver, a reverse transition occurs [1812.09920]. Illegal reads or writes can be redirected to fake pages under Monitor Trap Flag control [1812.09920]. In the reported benchmark, MemoryRanger measures approximately **170,000 ± 7,000** TSC ticks versus approximately **500,000 ± 10,000** for AllMemPro and approximately **100,000 ± 4,000** with no hypervisor and cache disabled [1812.09920].

At user level, “Practical Fine-grained Privilege Separation in Multithreaded Applications” introduces the **Arbiter Secure Memory Segment (ASMS)**, a shared segment whose pages are mapped at the same virtual addresses in all threads but with per-thread permissions derived from labels and ownerships [1305.2553]. Sensitive shared data is placed in ASMS, while stack and ordinary heap are private per thread [1305.2553]. The paper defines read and write conditions using ownership-aware label ordering, and all ASMS allocation and protection changes are mediated by the arbiter thread via specialized system calls [1305.2553]. The memcached port required changing only around **100 LOC**, and experiments report an average runtime overhead of **5.6%** [1305.2553].

Heap allocators provide yet another protection-oriented form. “SJMalloc” stores all heap metadata out-of-band, away from the application’s heap blocks, using **cells**, **bins**, and a reverse-lookup structure [2410.17928]. For small allocations it uses **FBINs** with 1024 cells and a bitmap; for medium allocations it uses **VBINs** with 32-bit cells of types **UH**, **FH**, **REF**, and **UN**; and for large allocations above **128 KB** it uses direct `mmap()` and an external lookup [2410.17928]. The security rationale is that classic allocator attacks rely on corrupting in-band metadata, whereas fully segregated metadata requires an arbitrary write into the metadata region itself [2410.17928]. The paper reports approximately **6%** performance improvement over glibc’s allocator at approximately **5%** additional memory cost, and states that SJMalloc passes the generic elements of the GLibc malloc testsuite [2410.17928].

## 5. Language-level regions, layouts, and static segregation

At the language level, memory segregation appears as a type- and effect-tracked partitioning of the heap. “Spegion” is a language with implicit non-lexical regions, splittable regions, and sized allocations [2506.02182]. Its central typing judgment is
\[
K \mid \Gamma \mid \Sigma \vdash e : (\tau,\rho) \mid \varphi
\]
where $(\tau,\rho)$ is a **type-with-place**, and $\varphi$ is an effect describing region actions such as `fresh`, `free`, `split`, and `alloc` [2506.02182]. Regions are created by `newrgn [s]`, deallocated by `freergn e`, and split by `split [s] e`, with capacities in $\overline{\mathbb{N}} = \mathbb{N} \cup \{\omega\}$ and static constraints such as `sumAllocs` ensuring that regions are not over-allocated [2506.02182]. The store itself is two-layered: an outer map from regions to inner stores plus capacities, and inner stores containing locations labeled by region [2506.02182]. The paper proves type safety with respect to a small-step operational semantics [2506.02182].

“Safely Abstracting Memory Layouts” presents **SHAPES**, where classes are parameterized by pools, pools have layout specifications, and objects in a pool may be split into clusters while preserving uniform source-level access such as `x.f` [1901.08006]. Pools are contiguous regions dedicated to objects of one class and one layout; layouts define clusters such as `rec { age, next }`; and the type system enforces pool **monomorphism** and **homogeneity** [1901.08006]. Objects in the global pool are ordinary records, while objects in a pool are represented by a location `(p,n)` indexing into pool clusters [1901.08006]. The dynamic semantics defines pooled allocation by appending null-initialized records to each cluster, and field access is resolved through layout-specific cluster and offset lookup [1901.08006]. The paper’s soundness theorem guarantees that evaluation from a well-formed heap and frame preserves well-formedness and expected type [1901.08006].

These language designs use “segregation” not primarily as a security boundary between principals, but as a static organization principle. Regions isolate lifetimes, capacities, and effects in Spegion [2506.02182]; pools and layouts isolate classes, field groups, and memory organization in SHAPES [1901.08006]. This suggests a common editor’s term, **semantic segregation**, for designs where the partition is enforced by typing and operational invariants rather than by page permissions or IOMMU state.

## 6. Physical fragmentation, non-VM addressing, and material segregation

At the physical-memory level, segregation also denotes the spontaneous division of RAM into small islands of free and used memory. “Characterizing Physical Memory Fragmentation” defines external fragmentation as a state in which total free memory is sufficient for a request but no single contiguous free run is large enough to satisfy it [2401.03523]. The study observes **248** Linux machines for a week and identifies six key memory-usage patterns [2401.03523]. It argues that Linux’s file cache and page reclamation systems are major contributors to fragmentation because they “obliviously break up contiguous memory,” reducing the ability to use huge pages [2401.03523]. The paper uses homogeneous physical regions as a proxy for contiguity and reports that free memory and homogeneity are correlated with $R^2 = 0.63$ [2401.03523]. In this sense, memory segregation emerges unintentionally from allocator, reclaim, and cache behavior.

“The Cost of Software-Based Memory Management Without Virtual Memory” studies systems without hardware virtual memory, where isolation is provided by physical protection hardware and software structure rather than by per-process virtual address spaces [2009.06789]. Memory is partitioned into fixed-size blocks, **32 KB** in the experiments, and applications must no longer assume large contiguous address ranges [2009.06789]. The paper uses segmented stacks and tree-based arrays to preserve useful abstractions over discontiguous physical memory [2009.06789]. Reported results include approximately **2%** average runtime increase for split stacks, **15%** slowdown for a pathological Fibonacci benchmark, and less than **3%** overhead from replacing large arrays with trees in the full applications examined [2009.06789]. Here segregation means explicit physical block ownership plus protection metadata, rather than virtual address-space separation.

Finally, in phase-change materials, “Chemical segregation in Ge$_2$Sb$_2$Te$_5$ thin films during in-situ heating” uses the term in a materials-science sense directly connected to electronic memory [2001.08100]. During heating of a **30 nm** GST film, the work observes Ge depletion in islands and Ge enrichment in inter-island regions, with oxygen localized in the gaps and the formation of amorphous Ge–O grain boundaries alongside Sb- and Te-rich crystalline domains [2001.08100]. The film crystallizes from amorphous to fcc at approximately **130°C** and to hexagonal GST at approximately **200°C**, while chemical segregation produces amorphous GeO$_x$ and Sb$_2$Te$_3$-like regions [2001.08100]. The authors state that such composition changes “would significantly impact” electrical and thermal properties in integrated devices [2001.08100]. This is a different disciplinary use of “memory segregation,” but it preserves the core notion of spatial separation into regions with distinct roles and effects.

Across these lines of work, memory segregation is therefore not a single technique but a family of mechanisms for imposing structure on memory. The structure may be architectural and adversarial, as in VM isolation and least-privilege translation control [1503.03169], [1908.08707], [2009.02737]; performance-oriented, as in hot/cold object reorganization and vertical partitioning [2510.19765], [1704.01198]; language-based, as in regions and typed pools [2506.02182], [1901.08006]; allocator-centric, as in out-of-band metadata [2410.17928]; or even physical and emergent, as in fragmentation [2401.03523]. What unifies them is the replacement of undifferentiated memory with partitions whose boundaries are intended to carry security, locality, authority, lifetime, or material semantics.

Source: https://www.emergentmind.com/topics/memory-segregation