---
title: Runtime Dependency Graph (RDG)
url: https://www.emergentmind.com/topics/runtime-dependency-graph-rdg
type: topic
---

# Runtime Dependency Graph (RDG)

A Runtime Dependency Graph (RDG) is a dynamically constructed, directed graph that precisely models execution-time dependencies between code units such as functions, methods, classes, microservices, or database actions. Unlike static call graphs derived from code structure, the RDG records actual invocations and operational dependencies observed during the execution of a program, workload, or transactional batch. RDGs are used for diverse purposes, including software engineering data synthesis, microservice benchmarking, dependency introspection, and concurrency control in distributed transaction processing. RDG construction, structure, and usage vary substantially across frameworks and domains, but all implementations emphasize runtime observation as opposed to static analysis.

## 1. Formal Definitions and Core Data Structures

An RDG is formally described as a tuple $(V, E)$, where $V$ is a set of runtime-activated nodes and $E \subseteq V \times V$ represents directed dependency edges. Node and edge semantics are instantiated differently by each system:

- **SWE-Flow** [2506.09003]:  
  - $V(f) \subseteq \mathrm{FN}$, with each function node $v = (\texttt{filepath}, \texttt{lineno}, \texttt{function\_name})$ captured during a test $f$.
  - $E(f) \subseteq V(f) \times V(f)$ records a directed edge $(u \to v)$ iff $u$ directly calls $v$ at runtime within $f$.
  - $\mathcal{S}_{\mathrm{RDG}} = \{(f, \mathrm{RDG}(f)) \mid f \in \mathcal{F}_{\mathrm{TTFN}}\}$ stores all per-test RDGs.

- **DGG for Microservices** [2412.19083]:  
  - $V = \{ (\text{ms}, \text{iface}, \text{label}) \}$ where each node is a microservice-interface triple, extended by operational labels.
  - $E = \{ (u \to v; w; t) \}$ encodes invocation $(u \to v)$ with weight $w$ denoting repeat count and $t$ as communication mode (e.g., http, rpc).

- **Classport** [2510.20340]:  
  - $V = \text{Dep} \cup \{\text{App}\}$, with application and dependency nodes.
  - $E_{\text{app}}$ and $E_{\text{dep}}$ connect application to used dependencies, and inter-dependency usage with $(d_1, d_2)$ iff at runtime a class from $d_1$ calls one from $d_2$.

- **DistDGCC** [1703.02722]:  
  - $V$ comprises “record-action” vertices, each $(T.\text{id}, \text{tableName}, \text{primaryKey}, \text{opType}, \text{parameters})$ for a transactional operation.
  - $E$ includes logical (program-order), temporal (conflict), and node (cross-partition) dependencies, structuring the per-batch RDG as a DAG.

## 2. Construction Algorithms and Instrumentation

RDG generation requires runtime instrumentation to log dependencies:

- **SWE-Flow**:  
  Utilizes Python's `sys.setprofile` API. The runtime hooks each function entry/exit, maintaining a stack $S$ of activation records. For every function call in the project, it records caller/callee edges in $E$. Time and space complexity are $O(C)$, where $C$ counts call events within test execution.

- **DGG**:  
  Ingests production tracing records (e.g., Jaeger, Alibaba RPC), extracting a per-request call graph CG = $(V, E)$. Multiple per-request call graphs are merged per-service $S$ to yield $G_S = (V_S, E_S)$, optionally collapsing repeated edges and tracking invocation weights. The final generator samples synthetic topologies using conditional probabilities $P(u \to C \mid s, d)$, where $u$ is a parent, $C$ a children-set, $s$ siblings, and $d$ depth, derived from empirical traces.

- **Classport**:  
  Bytecode instrumentation injects dependency metadata (@ClassportInfo annotation) into every Java class at build time. At runtime, a Java Agent collects the set of dependencies actually traversed, building the RDG by mapping observed method entries and dynamic invocations to dependencies via the mapping $M : C \rightarrow \text{Dep}$.

- **DistDGCC**:  
  Parses each transaction batch into record-actions, maintaining per-record state ($\text{lastWrite}[r]$, $\text{readers}[r]$). It incrementally constructs logical, temporal, and node-dependency edges, representing each batch as an acyclic RDG. This enables append-only, lock-free construction and massive parallelism for batch processing.

## 3. Applications Across Domains

| Framework | RDG Node Type        | RDG Edge Semantics                  | Principal Application              |
|-----------|----------------------|-------------------------------------|------------------------------------|
| SWE-Flow  | Function (Python)    | Runtime call (direct)               | TDD data synthesis, increments     |
| DGG       | Microservice-Interface | Runtime invocation, weighted, typed | Microservice call benchmarking     |
| Classport | Java Dependency      | Dependency usage at runtime         | Supply chain security, introspection|
| DistDGCC  | Record-Action        | Conflict, logical, node dependency  | Concurrency control, recovery      |

- **Software Engineering (SWE-Flow)**: RDG defines the mapping from unit tests to the sequence-minimal set of functions needing implementation at each TDD step. This powers the derivation of incremental development schedules and enables faithful, test-driven code/task synthesis [2506.09003].

- **Microservices (DGG)**: Fine-grained RDGs, capturing interface dynamics and invocation modality, enable realistic benchmarking and drive autoscalers that tune resource allocation based on current execution structure (FineGrained-Scale), attaining up to 44.8% CPU resource savings while maintaining QoS [2412.19083].

- **Java Supply Chain Security (Classport)**: RDG introspection exposes which dependencies are actually active at runtime, supporting integrity validation, forensic auditing, and detection of unused or vulnerable third-party code [2510.20340].

- **Distributed Transaction Processing (DistDGCC)**: RDGs synchronize, parallelize, and log distributed transactions. This DAG-centric methodology eliminates the need for classical locking, allows fast parallel recovery, and fundamentally underpins dependency logging and conflict-serializable concurrency [1703.02722].

## 4. Illustrative Examples

- **SWE-Flow**: For a project with functions `add` and `mul` and corresponding tests, two RDGs are generated:
  - For `test_sum`: $V = \{\text{test\_sum}, \text{add}\}$, $E = \{(\text{test\_sum} \to \text{add})\}$
  - For `test_area`: $V = \{\text{test\_area}, \text{mul}\}$, $E = \{(\text{test\_area} \to \text{mul})\}$
  - Deeper chains appear for nested calls, e.g., `test_sum → add → log_call` [2506.09003].

- **DGG**: Each microservice request trace yields a call graph CG with edge weights representing repeated calls and labels encoding communication mode. Merging call graphs results in a service-level RDG with synthetic graph generation driven by cluster-wise conditional probabilities reflective of production traces [2412.19083].

- **Classport**: At runtime, a HashSet $S$ records observed dependencies. Edges from App → Dep and Dep → Dep are reconstructed from call data, effectively forming a star or general usage graph for the executed workload [2510.20340].

- **DistDGCC**: Each batch of transactions forms a DAG where vertices are per-tuple record actions; edges of temporal and logical flavor encode all ordering necessary for serializability and recovery. Logging and recovery operate directly over this structure [1703.02722].

## 5. Analytical Properties and Performance

The asymptotic and empirical properties of RDG construction and usage are as follows:

- Time and space complexity are dominated by the number of events or actions traced ($O(C)$ in SWE-Flow, $O(|V| + |E|)$ elsewhere).
- In microservices, DGG-generated RDGs yield distributions (depth, node count, topology) nearly indistinguishable from real production traces, with Jensen–Shannon divergence for depth and node-count at 0.034 and 0.053, respectively (substantially better than topology-agnostic benchmarks) [2412.19083].
- In transactional systems, batch-wise RDG construction enables 2–3× higher throughput versus lock-based approaches under high contention, with dependency logging supporting up to 5× faster parallel recovery [1703.02722].
- For Java build systems, injection of runtime dependency metadata by Classport adds minimal build and runtime overhead (1–2% of build time, 0.74–4.27% runtime slowdown, 10–29% jar size increase), with perfect recall/precision for actively executed dependencies [2510.20340].

## 6. Comparative Perspective and Limitations

RDGs fundamentally contrast with static dependency analyses by reflecting only executed paths and actual runtime behavior, thus providing minimal and accurate coverage sets for data synthesis, resource planning, and recovery.

However, observed limitations include:
- Incompleteness if workload does not activate all potential paths or classes (Classport: misses dependencies absent from execution) [2510.20340].
- Potential memory overhead for large-scale traces or large transactional batches in microservices and distributed databases.
- In distributed transactions, the requirement for batch arrival and DAG closure can create latency trade-offs under latency-sensitive workloads [1703.02722].
- Metadata injection and annotation (Classport) can invalidate package signatures, raising deployment and security complexities [2510.20340].

Future work across systems includes expanding introspection coverage, supporting streaming or incremental execution models, and securing or validating metadata against runtime tampering. In microservice settings, further refinement of RDG-based autoscaling strategies remains an open area for efficiency gains [2412.19083].

## 7. Integration into Systems and Workflows

RDGs serve as the orchestration backbone in several advanced frameworks:

- **SWE-Flow** leverages the RDG for incremental deconstruction of codebases, derivation of verifiable TDD tasks, and structured repository reconstruction from test-driven evidence [2506.09003].
- **DGG** integrates RDGs in a data-driven loop to drive both benchmarking and online resource scaling, with clustering enabling adaptive, production-realistic benchmarking [2412.19083].
- **Classport** embeds RDG-centric introspection natively into Java application lifecycles using agent-based runtime data collection for security and supply-chain analyses [2510.20340].
- **DistDGCC** deploys per-batch RDGs for lock-free, deterministically parallel execution and recovery—linking concurrency control, logging, and replay into a single, highly effective operational paradigm [1703.02722].

Source: https://www.emergentmind.com/topics/runtime-dependency-graph-rdg