Instance Dynamic Memory in Computational Systems

• IDM is a research concept characterized by explicit memory mechanisms that dynamically update storage during execution.
• It is applied in domains such as MPSoC co-simulation, few-shot continual learning, and dynamic scene reconstruction through tailored allocation, update, and retrieval policies.
• Implementations of IDM use techniques like pointer tables, PCM-based hardware, and cluster-based replay to balance simulation accuracy, capacity constraints, and real-time performance.

Across the cited literature, Instance Dynamic Memory (IDM) is not a single canonical architecture but a family of mechanisms in which an external memory evolves during execution rather than remaining fixed. The common pattern is explicit storage, online update, and retrieval at the level of pointers, classes, instances, scenes, or temporally persistent clusters. This pattern appears in dynamic memory integration for MPSoC co-simulation, in dynamically evolving explicit memories for few-shot continual learning, in cluster-based replay for continual traversability learning, and in category- or instance-organized memories for perception and reconstruction (0710.4646, Karunaratne et al., 2022, Ma et al., 2024, Krishna et al., 2023, Mao et al., 1 Apr 2025).

1. Terminological scope

Within systems and learning research, the label IDM is used heterogeneously. A low-level precursor appears in dynamic memory integration for C/C++/SystemC MPSoC co-simulation, where simulated memory operations are mapped onto the host machine’s native memory management while cycle-true wrappers preserve timing and communication semantics (0710.4646). In continual traversability learning, IMOST uses IDM explicitly as incremental dynamic memory, a scene-aware replay mechanism that creates new clusters under an information expansion criterion and updates existing clusters by a diversity rule (Ma et al., 2024). In few-shot continual learning hardware, the memory core is described as an IDM-like dynamically evolving explicit memory coupled to a stationary deep neural network controller and realized on a PCM in-memory compute core (Karunaratne et al., 2022).

Adjacent work often implements the same underlying idea without using the exact name. MILA introduces a memory module that dynamically stores pooled features of labeled source instances, organized by category, for cross-domain instance alignment (Krishna et al., 2023). UnIRe constructs temporally consistent 4D superpoints and canonical-space deformation histories for dynamic instances, yielding a memory-like instance representation over time (Mao et al., 1 Apr 2025). Mem4D decouples memory for transient motion and persistent structure through a dual-memory design, separating short-term dynamic detail retention from long-term static consistency (Cai et al., 11 Aug 2025).

This distribution of usages indicates that IDM is best treated as a research concept centered on dynamic, explicit, online-updated memory, rather than as a single standardized module name.

2. Shared architectural pattern

The strongest commonality across IDM formulations is explicitness. In the PCM-based few-shot continual learning system, a stationary controller produces 256-dimensional quasi-orthogonal vectors; support examples are written as 1-bit bipolar support vectors, queries are represented as 8-bit query vectors, and inference is performed by in-memory similarity search with the classification rule

$\hat{y} = \arg\max_c \; s(q, m_c).$

The memory expands when a previously unseen class appears and physically superposes multiple examples of the same class into one class vector through progressive crystallization of PCM devices (Karunaratne et al., 2022).

In IMOST, memory is organized around an image node

$$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$

where $F[M]$ denotes traversable-region features restricted by the mask $M$. Novelty is decided by Jensen–Shannon divergence, with a new cluster created when

$$\min\{D_{JS}(V_{new}, V_{c_1}), \ldots, D_{JS}(V_{new}, V_{c_k})\} \geq \lambda .$$

Otherwise, the node is assigned to the nearest cluster and retained according to a diversity-preserving update rule (Ma et al., 2024).

In MPSoC co-simulation, explicitness takes a more literal systems form. The wrapper maintains a pointer table containing Vptr, Hptr, Type, Dim., and Res. and translates simulated requests into host-side operations such as calloc(dim, DATA_SIZE) and free() (0710.4646). The memory state is therefore not hidden in model parameters; it is directly addressable, inspectable, and updateable.

Across these cases, IDM combines four recurrent operations: allocation or expansion, update, retrieval, and capacity or coherence control. Allocation may mean generating a new virtual pointer, selecting a fully reset PCM column for a new class, or instantiating a new cluster when divergence exceeds $\lambda$. Update may mean writing host memory, physically superposing support vectors, or retaining both central and diverse nodes in a cluster. Retrieval may mean pointer translation, in-memory similarity search, or cluster-balanced replay. Capacity control appears as finite-size allocation limits, one-column-per-class storage growth, per-cluster capacity $n_{max}$, or temporal compression of older memory entries. This suggests that the main differentiator of IDM is not the substrate itself, but the policy by which new information is admitted, represented, and read out.

3. Systems-oriented realization in co-simulation

A concrete systems realization of IDM appears in dynamic memory integration for MPSoC co-simulation. The framework is layered into a software layer with application code and API, a design model layer with ISSs, interconnect, memories, and wrappers, a simulation kernel based on C++ / SystemC simulation control, and a host machine layer consisting of host OS, host MMU, and host memory. The memory subsystem is implemented as wrapper memories in C/C++/SystemC (0710.4646).

The wrapper has two parts. The cycle-true part is a Finite State Machine (FSM) that processes communication cycle by cycle, implements a handshake protocol, interprets transaction opcodes, and enforces timing and delay behavior. The functional part contains a pointer table and a translator that handle endianess, data type translation, and the mapping between simulated and real memory. Each transaction begins with opcode and sm_addr, followed by operation-specific fields such as dim, type, Vptr, DataIn, or DataOut.

Allocation proceeds by sending dim and type from the ISS, invoking calloc(dim, DATA_SIZE) on the host side, storing the returned real pointer Hptr in the pointer table together with type and dimension, and returning a simulated virtual pointer Vptr to the ISS. The first Vptr is 0 by default, and subsequent Vptr values are generated by adding the size of the previous allocated space to the previous Vptr. Read and write operations resolve Vptr through the pointer table, then load from or store into host memory. Deallocation removes the corresponding table entry, compacts the table, updates total memory usage, and calls host free() using the associated Hptr. Pointer arithmetic is supported by searching the table for the allocated region containing an interior address and computing the correct Hptr offset.

Two further mechanisms are central. First, the reservation bit Res. functions as a semaphore-like mechanism for preserving coherence in shared-memory access. Second, a set of delay parameters in the FSM preserves simulation accuracy even though actual storage is delegated to host memory. A finite memory can be modeled by refusing new allocations once the sum of all allocated dimensions reaches a predefined limit. Multiple memory instances are straightforward because the host machine generates a different host pointer for every allocation.

The preliminary evaluation uses the GSM algorithm and compares 4 ISSs + one memory + interconnect against 4 ISSs + interconnect + 4 memories. The reported simulation speed degradation of 20% is presented as evidence of very low overhead for a model that supports dynamic data processing with cycle-true behavior (0710.4646).

4. Explicit memory in continual learning

In few-shot continual learning, IDM appears as a dynamically evolving explicit memory tightly coupled to a fixed controller. The controller is a ResNet-12 trained in software during the first session and then frozen. It maps images into 256-dimensional quasi-orthogonal vectors, with $d=256$ chosen so that the vector fits an entire column of the PCM crossbar array. New support examples are encoded as 1-bit bipolar support vectors and written into memory, while inference-time queries are encoded as 8-bit query vectors and compared against stored class vectors by a 4-quadrant matrix-vector multiply (MVM) on the crossbar. The memory is implemented on the Hermes chip, using a 256 × 256 unit-cell array of PCM devices, with each unit-cell containing 4 PCM devices, though only 2 are used in this experiment (Karunaratne et al., 2022).

The key operation is physical superposition. If a support-vector element is $+1$, conductance is increased in the positive device of a differential pair; if it is $-1$, conductance is increased in the negative device. The first example of a new class allocates a fully reset column; later examples of that class are superposed through in-situ progressive crystallization using SET pulses. The resulting storage scales approximately as

$$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$0

rather than

$$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$1

On CIFAR-100 and miniImageNet, the IMC-based explicit memory remains within 1.28%–2.5% of the state-of-the-art full-precision software baseline while continually learning 40 novel classes from five examples per class on top of 60 old classes (Karunaratne et al., 2022).

In IMOST, the memory is scene-aware rather than class-addressed. Traversability learning is framed as Domain-Incremental Learning (DIL) under online streams that do not provide scene identifiers. IDM clusters samples by traversable-region feature statistics, uses Jensen–Shannon divergence to detect new scene distributions, and stores only a compact representative subset per cluster. The experiments set threshold $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$2 and cluster capacity = 20. During replay, clusters are sampled with equal probability $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$3, nodes are sampled with inverse cluster-size weighting, and normalized reconstruction loss acts as a proxy for uncertainty (Ma et al., 2024).

The empirical role of IDM in IMOST is not merely organizational. On the self-collected dataset, the paper states that IDM creates 5 clusters and stores 100 images, while the ablation reports AUROC 0.9725, F1 0.9725, IoU 0.9463 for full IMOST versus AUROC 0.9589, F1 0.9319, IoU 0.8775 for the variant w.o. IDM. This positions IDM as a mechanism for maintaining scene-aware knowledge diversity while preserving compact memory capacity (Ma et al., 2024).

5. Instance-level retrieval and temporally persistent memory

A related line of work instantiates IDM at the level of object proposals and tracked dynamic entities. In MILA, the memory module dynamically stores pooled features of all labeled source instances, categorized by their labels. For a source box $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$4, the pooled feature is

$$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$5

and only correctly classified source instances are retained in memory. The memory bank is category-indexed as $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$6, and for each confident target proposal the method retrieves the top-$$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$7 most similar same-category source instances using cosine similarity. Memory is updated after every $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$8 of an epoch, and the retrieved source instances drive a similarity-weighted contrastive alignment loss. The reported benchmark results include 44.6 mAP on Pascal VOC $$\mathcal{N}(F, M, V), \qquad V = [\mu(F[M]), \sigma(F[M])],$$9 Comic2k, 63.7 mAP on Pascal VOC $F[M]$0 Watercolor2k, 50.6 mAP on Cityscapes $F[M]$1 FoggyCityscapes, and 57.4 car AP on Sim10k $F[M]$2 Cityscapes (Krishna et al., 2023).

In UnIRe, the memory-like unit is a 4D superpoint, defined as a temporally consistent cluster

$F[M]$3

constructed by propagating per-frame LiDAR clusters through scene-flow matching. Matching between adjacent frames is determined by

$F[M]$4

Over-segmented superpoints are then merged through a spatiotemporal similarity matrix

$F[M]$5

For each dynamic instance, a canonical frame

$F[M]$6

is selected, and per-point deformation is initialized by accumulated instance flow

$F[M]$7

This yields temporally persistent instance representations that support instance-level editing such as removing one vehicle or replacing one pedestrian (Mao et al., 1 Apr 2025).

In Mem4D, the same design objective is generalized to dynamic scene reconstruction through a dual-memory architecture. The Transient Dynamics Memory (TDM) captures high-frequency motion details from recent frames, while the Persistent Structure Memory (PSM) compresses and preserves long-term spatial information. Readout alternates between motion and spatial memory blocks,

$F[M]$8

so that dynamic detail and global geometric consistency are refined in sequence. PSM is maintained as a FIFO queue of size $F[M]$9, and the initial memory frame $M$0 is never removed or compressed. The system is reported to run at about 16 FPS (Cai et al., 11 Aug 2025).

These examples indicate that instance-level IDM can be realized as a category-wise feature bank, a temporally consistent cluster track, or a decoupled motion/structure memory. The shared principle is the same: persistent external state is used to recover reliable correspondences that a purely local or per-frame computation would miss.

6. Limitations, trade-offs, and acronym overload

IDM designs are constrained by the substrate and by the reliability of the statistics used to populate memory. The MPSoC co-simulation framework is explicitly a first prototype in a shared memory context; methods for general data structures are work in progress, and the paper does not provide a full formal proof of correctness or exhaustive benchmarking (0710.4646). The PCM explicit memory depends on a fixed embedding dimension $M$1 chosen to match crossbar geometry, uses 1-bit support vectors and 8-bit query vectors, relies on a differential pair although only two of the four devices in each unit-cell are used, and assumes that few-shot updates stay within the available conductance range (Karunaratne et al., 2022). In IMOST, the update strategy is described as retaining both the most similar and most diverse image nodes to the cluster center, but the paper does not provide a more explicit equation or pseudocode for that rule (Ma et al., 2024).

A common misconception is that IDM necessarily implies unbounded memory growth. The cited systems generally impose explicit bounds: co-simulation wrappers can deny allocations when total size reaches a predefined limit, the PCM memory grows with the number of classes rather than the number of stored examples, IMOST fixes a maximum per-cluster capacity, and Mem4D compresses older structural information. This suggests that “dynamic” in IDM usually denotes adaptive admission and update, not unconstrained expansion.

Another recurrent source of confusion is the acronym itself. In PerSense, IDM denotes Instance Detection Module, a training-free component that converts density maps into candidate point prompts through thresholding, erosion, contour extraction, and composite-contour splitting, rather than any form of dynamic memory (Siddiqui et al., 2024). In collider phenomenology, IDM usually denotes the Inert Doublet Model, a two-Higgs-doublet extension of the Standard Model with a stable dark matter candidate (Klamka et al., 2022). In traffic modeling, IDM is the Intelligent Driver Model, a second-order car-following ODE system (Albeaik et al., 2021). For this reason, the meaning of IDM must be inferred from domain context.

Taken together, the literature supports a narrow but robust characterization: Instance Dynamic Memory refers to architectures that keep memory explicit, update it online, and organize it around persistent units of computation such as allocations, classes, proposals, scenes, or dynamic instances. The implementation may be a pointer table, a cluster buffer, a PCM crossbar, a category-wise feature bank, or a dual-memory reconstruction module, but the defining property is the same—the system’s effective knowledge is carried not only by a model or processor, but also by a mutable external memory with domain-specific admission, retention, and retrieval rules.