Memory Dependency Graph Overview

• Memory Dependency Graph is a graph-based model representing memory constraints through explicit or implicit relations among memory entities.
• It is applied across diverse domains such as compiler optimization, microarchitectural prediction, and task scheduling to manage access, ordering, and propagation.
• The model enhances system performance and correctness by exposing critical relations like read-after-write, version dependencies, and execution order constraints.

Searching arXiv for recent and foundational papers related to “memory dependency graph” and closely related formulations. A memory dependency graph is a graph-structured representation in which memory-relevant entities are connected by relations that constrain access, ordering, reuse, validity, or propagation. In the literature surveyed here, the term does not denote a single canonical formalism. Some works construct explicit graphs over variables, transaction pieces, tasks, revisions, package versions, or reasoning steps; others maintain graph-like summaries in which dependence is encoded only implicitly through predictor tables, reordering structures, or learned embeddings. Across these variants, the common role of the graph is to expose relations that matter for correctness or performance, such as read-after-write constraints, execution order, provenance, support, supersession, or downstream impact (Alluru et al., 2021, Westrick et al., 2022, Park, 18 Mar 2026).

1. Scope and terminological variation

A common misconception is that a memory dependency graph must always be an instruction-level graph whose nodes are loads and stores. The surveyed literature shows a broader landscape. In compiler-oriented work, the graph may center on variables or memory objects rather than statements. In architecture, the underlying relation may be a dynamic load-to-store dependence or an equivalence relation over irregular accesses. In task parallelism and transactional systems, the relevant graph is an execution or precedence DAG sufficient to decide whether two memory accesses are ordered. In data analytics and software ecosystems, the graph may instead encode dependency among cached blocks or vulnerable package versions. In persistent and agentic memory systems, memory dependency is expressed as provenance, Depends_On, Supersedes, or parent links over revisions and reasoning steps (Panayi et al., 9 Apr 2026, Yao et al., 2015, Yu et al., 2017, Wu et al., 24 Apr 2026).

This variation is not merely terminological. It changes what the nodes mean, what the edges assert, and what algorithms can be supported. A graph over variables supports local dependence tests and source-to-source transformations; a graph over transaction pieces supports topological execution; a graph over revisions supports rollback, provenance, and impact analysis; a graph over package versions supports propagation analysis under semantic-version resolution. The literature therefore treats “memory dependency graph” less as one fixed data structure than as a family of dependency-carrying graph models specialized to different memory semantics.

2. Instruction-level and object-level dependence

The most direct explicit formulation in the surveyed material is the graph-based Data Dependence Identifier. It parameterizes a program as $P(I, V \cup \{HU, PR\}, MAI)$, where $I$ is the instruction set, $V$ is the set of variables or memory allocations, $MAI$ is the set of memory-access instructions, $HU$ denotes hardware units, and $PR$ denotes programmer-provided constants. The program graph is $G_P = (V \cup \{PR,HU\}, E, L)$. For each memory-access instruction represented as $[R,W]$, edges $(r,w)$ are added for all $r \in R$ and $I$0, with the instruction index as label. In this model, nodes are memory objects, not statements; dependence is recovered through graph patterns over incoming and outgoing labeled edges. A path of length two through a node $I$1, $I$2, indicates a data-dependence problem through the shared memory object $I$3. The same framework is stated to cover flow dependence, anti dependence, output dependence, and input dependence, and the paper claims polynomial-time identification plus support for dead code elimination, constant propagation, and induction variable detection (Alluru et al., 2021).

At the microarchitectural level, the same underlying idea appears in more compressed or implicit form. In profile-guided memory dependence prediction, the “true underlying relation” is between dynamic loads and older dynamic stores that may write the same address. Practical predictors such as Store Sets do not preserve that full relation; instead they maintain a compressed summary through PCs, Store Set IDs, and LFST entries. The paper interprets this summary as an implicit graph approximation in which static instruction PCs behave like nodes, observed violations create or reinforce edges, and aliasing-induced collisions create spurious edges. Its contribution is to prune consistently memory-independent loads from that implicit graph by labeling them so that they bypass the memory dependence predictor entirely. On SPEC2017 CPU intspeed, this reduces the rate of MDP queries by 79%, reduces false dependencies by 77%, and improves geomean IPC for a small simulated core by 1.47%, reaching within 0.5% of using 16x the predictor entries, with no area cost and no additional instruction bandwidth (Panayi et al., 9 Apr 2026).

A different hardware analogue appears in the Irregular accesses Reorder Unit for graph workloads. That paper does not define a memory dependency graph explicitly, but its closest analogue is a dynamic equivalence relation over irregular accesses. Two accesses are treated as related when they target the same cache line or block, or the same indexed element; that relation drives grouping, deduplication, and response remapping. The reordering hash thus acts as an online structure for discovering related memory operations across warps and SMs. Quantitatively, the IRU reports a memory coalescing improvement of 1.32x, a 46% reduction in overall traffic in the memory hierarchy, 1.33x performance improvement, 13% energy savings, and 5.6% area overhead (Segura et al., 2020).

3. Execution-order graphs and scheduling over shared state

Several systems use graphs that are not themselves memory-dependence graphs in the compiler sense, but are sufficient to infer when memory accesses are ordered. DePa is explicit on this point. It addresses the parallel order maintenance problem for nested fork-join parallelism by representing execution as a computation DAG whose vertices are sequences of instructions uninterrupted by fork or join, and whose edges are ordering constraints. Each vertex is labeled with a dag-depth and a fork-path. The central query is whether $I$4, meaning that there is a path from $I$5 to $I$6. For current leaf-task vertices, DePa answers precedence queries in $I$7 work, where $I$8 is the minimum dynamic nesting depth of the compared vertices and $I$9 is the machine word size. In dynamic race detection, that structural order test is precisely what determines whether two accesses to the same location could race (Westrick et al., 2022).

DGCC lifts this idea to transactional execution. Its dependency graph is built over transaction pieces rather than memory operations. Vertices are transaction pieces; edges represent either logic dependency within one transaction or timestamp ordering dependency between conflicting pieces from different transactions. The graph is constructed before execution, so that conflicts are resolved in advance and the runtime phase becomes a topological execution over zero in-degree vertices. The paper argues that the resulting schedule is conflict-serializable and reports up to four times higher throughput than state-of-the-art concurrency-control protocols for high-contention workloads (Yao et al., 2015).

In data analytics clusters, the dependency graph shifts again from operations to data products. LRC uses the application DAG of RDD computations as a cache-management signal. For a block $V$0, the reference count is the number of child blocks derived from $V$1 that have not yet been computed, which can be written as $V$2. Eviction chooses the cached block with smallest reference count. Here the graph captures future-use dependence rather than correctness dependence: once all descendants of a block have been materialized, the block is inactive. The paper reports that median 77% and 95th percentile 99% of cached data was inactive across 15 SparkBench applications, and that LRC speeds up typical applications by 60% relative to LRU (Yu et al., 2017).

4. Learned surrogates and indirect semantic graphs

Not all graph-based reasoning about memory builds explicit dependence edges. GraphSpy is exemplary in this respect. It addresses dead-store detection through a fused semantic representation composed of a static intra-procedural CFG, a dynamic inter-procedural calling context tree, sampled dynamic memory state attached to CCT nodes, and a ResNet-based view of the CFG adjacency matrix. The task is graph-level classification: each procedure is embedded and classified as suspicious or not for dead stores. The paper defines a dead store as a case in which two consecutive store instructions to the same memory location are not intervened by a load instruction for the same location. Yet the graph does not contain direct store-to-load, store-to-store overwrite, alias, or happens-before edges. Memory dependence is represented only indirectly through control-flow topology, dynamic calling context, memory-state features, and message passing (Guo et al., 2020).

This indirectness is methodologically important. GraphSpy is memory-aware but not memory-dependence-explicit. Its graph is a learned surrogate for dependence-relevant behavior, not an exact dependence graph. The paper reports average precision 88.14%, average recall 88.55%, average accuracy 88.08% across configurations, and 90.02% accuracy in the hybrid setting. Used as a filter before CIDetector, it yields an average speedup of 1.65x over whole-program CIDetector, with a maximum speedup of 1.89x and about 40% memory-overhead reduction (Guo et al., 2020).

5. Dependency-structured memory in AI agents

Recent agent-memory systems make dependency structure explicit again, but over reasoning states rather than machine memory operations. ContextWeaver organizes an interaction trace as a DAG of reasoning steps. Each step $V$3 is turned into a node

$V$4

Edges denote logical or causal dependency between steps. Parent selection is formulated as

$V$5

and future context is built by backward traversal over the ancestry of the current node. Failed or superseded nodes are excluded from future parent selection. On SWE-Bench Verified and Lite, the paper reports improved pass@1 over a sliding-window baseline in some model settings, lower variance in five-run experiments, and DAG-vs-tree results of $V$6 versus $V$7 on the 100-instance Verified subset (Wu et al., 24 Apr 2026).

Dep-Search makes a related move in search-augmented reasoning. Its search state is

$V$8

where $V$9 is a dependency-aware reasoning trace, $MAI$0 is current context, and $MAI$1 is an LRU memory buffer. The paper states that dependencies between sub-questions form a directed acyclic graph structure, with updates

$MAI$2

Memory entries are summarized fact sentences, and the buffer is updated under a recency rule with fixed capacity $MAI$3. Ablations on Qwen2.5-3B report 39.29 average score for full Dep-Search, 35.97 without QDMR Decompose, 34.04 without the Memory Module, and 37.30 without Conclusion, indicating that explicit decomposition and persistent memory are central rather than auxiliary (Liu et al., 26 Jan 2026).

Kumiho generalizes this design into a graph-native long-term memory with formal revision semantics. Its graph is

$MAI$4

where $MAI$5 is the set of items, $MAI$6 is the set of revisions, $MAI$7 is the set of typed directed edges between revisions, and $MAI$8 is a partial function from tag names to revisions. Dependency is expressed explicitly by edge types such as Depends_On, Derived_From, and Supersedes. The active belief base is induced by tags,

$MAI$9

so revision is implemented operationally by adding a new immutable revision, adding a Supersedes edge, and moving a tag rather than overwriting memory. The paper proves satisfaction of the basic AGM postulates $HU$0–$HU$1 and Hansson’s Relevance and Core-Retainment in this belief-base setting, and reports 0.565 overall F1 on LoCoMo and 93.3% judge accuracy on LoCoMo-Plus (Park, 18 Mar 2026).

6. Dependency graphs for propagation and ecosystem-scale memory risk

A further extension appears in ecosystem security, where the graph tracks how vulnerable states propagate through versioned dependencies. The Cargo dependency-vulnerability knowledge graph contains three node types—library, library_version, and cve—and four relation types: has, library_affects, version_affects, and version_depends. Its reported size is 570,563 nodes and 4,023,703 edges. The graph itself stores a library_version -> library dependency relation, while a separate parser applies Cargo’s official parsing rules and semantic-version constraints to determine the actual resolved version and thus the actual propagation path (Jia et al., 2022).

This distinction between static reachability and resolved propagation is essential. The parser filters development dependencies, optional dependencies, and feature conditions, then chooses a compatible version under Cargo’s semantic-versioning conventions. The result is a vulnerability propagation analysis at both library level and version level. The paper reports that the Cargo ecosystem’s security vulnerabilities are primarily memory-related; that 18% of the libraries affected by the vulnerability is still affected by the vulnerability in the latest version of the library; that 21,722 libraries and 97,779 versions are affected by propagated vulnerabilities; and that this corresponds to 28.61% of all libraries and 19.78% of all versions in the ecosystem. It also states that the spread of vulnerabilities caused by pass-through dependencies is about ten times greater than direct dependencies (Jia et al., 2022).

Taken together, these results suggest that “memory dependency graph” is best understood as a domain-specific design pattern rather than a single object. In some settings the graph carries exact dependence and ordering constraints; in others it is a compact approximation, a provenance structure, or a version-aware propagation model. The persistent theme is that graph structure is introduced when flat histories, recency heuristics, or local predictors fail to preserve the relations on which later correctness, performance, or interpretation depends.