Heap memory 2026-10-24
Storage used for heap allocation, with software object lifetimes not necessarily nested like procedure calls on a call stack. Garbage collection can reclaim unreachable software objects; keeping references to every allocated software object prevents that reclamation regardless of how little of each software object's data a program still needs.
Memory compaction 2026-11-05
Memory compaction moves live data so that free computer memory can be collected into larger contiguous regions. It changes data placement, while memory block coalescing combines intervals that are already free and adjacent. Compaction therefore needs a way to preserve the meaning of references to moved data. An ordinary allocator cannot freely move an arbitrary live C programming language allocation behind unchanged raw pointers.[ref]
Consider the104-byte pool with free blocks of24,40 and16 bytes, separated by live blocks of16 and8 bytes. Its total free capacity is80 bytes, but its largest free memory block is40 bytes. If both live blocks are movable, placing the16-byte object at offset0 and the8-byte object at offset16 creates one free80-byte interval from24 to104. No additional capacity is created; its contiguity improves.
The references must follow each movable memory object. A reference to offset24 in the original first object becomes offset0; a reference five bytes inside that object changes from29 to5. A garbage collection system with accurate reference information or another suitable level of indirection can arrange such updates. Blindly replacing every integer equal to an old address would corrupt unrelated data.
Physical-page compaction is a different allocation-layer application. An operating system can move eligible pages while preserving a process's virtual memory addresses through updated mappings. Linux's documented compaction mechanism seeks contiguous free physical blocks, including for large-page allocation; moving pages also has execution costs and can affect latency.[ref] Such physical rearrangement does not automatically combine separated virtual heap holes. The address space, movable objects and reference-preservation mechanism must accompany a compaction claim.
Movable memory object 2026-11-05
A movable memory object is a live allocation that its memory-management system may relocate while preserving its identity and valid references. Moving the stored bytes is only part of the operation: references must be updated, or an indirection mechanism must continue to locate the object. This capability permits memory compaction. Microsoft's primary runtime documentation describes separate marking, reference-relocation and object-compaction phases of garbage collection.[ref]
For an illustrative16-byte object initially starting at offset24, compaction may place its bytes at offset0. A reference to its beginning then changes from24 to0; a reference five bytes inside it changes from29 to5. In general, moving the base from to maps a tracked interior reference to . An unrelated integer with value29 must not be rewritten merely because it resembles the old address.
The memory manager therefore needs reliable knowledge of roots and references, including those held in other live objects. A garbage collection root can keep an object reachable while its address changes. If an external consumer requires the address to stay fixed, a pinned memory object imposes a relocation constraint instead. Movability is a property of the reference-management arrangement, not simply of whether the object contains bytes that can be copied.
A raw C programming language pointer returned by an ordinary allocator generally prevents arbitrary hidden movement, because the allocator does not control all copies of that address.[ref] Physical-page movement under virtual memory is another layer: an operating system may preserve virtual addresses while changing the underlying physical mapping. It need not make the application-level object movable in its own address space.
Choose a circular doubly linked list with a permanent dummy list header. For a concrete Oberon definition take data = INTEGER; the same link operations work with any chosen data data type:
TYPE data = INTEGER;
     pointerToNode = POINTER TO node;
     node = RECORD
       value : data;
       prev, next : pointerToNode
     END;

PROCEDURE NewList() : pointerToNode;
VAR h : pointerToNode;
BEGIN
  NEW(h);
  h.prev := h;
  h.next := h;
  RETURN h
END NewList;

PROCEDURE Insert(v : data; n : pointerToNode);
VAR t, p : pointerToNode;
BEGIN
  p := n.prev;
  NEW(t);
  t.value := v;
  t.prev := p;
  t.next := n;
  p.next := t;
  n.prev := t
END Insert;

PROCEDURE Delete(n : pointerToNode);
VAR p, q : pointerToNode;
BEGIN
  p := n.prev;
  q := n.next;
  p.next := q;
  q.prev := p;
  n.prev := NIL;
  n.next := NIL
END Delete;
The representation invariant is that the live nodes and header form one finite circular chain, with every neighboring next/previous pair mutually consistent. Insert replaces the link by . Delete replaces by . All other links remain unchanged. These arguments also cover insertion into an empty linked list and deletion of its sole data node, where the neighboring positions can refer to the same header.
Insert requires a live node n belonging to this representation and successful allocation. It may be called with n equal to the header, meaning append just before the end. Delete requires a live data node and must never be called on the header, on NIL, or on a node already deleted or belonging to an incompatible representation. The signature alone cannot enforce those preconditions. The detached node is left for garbage collection; external references must no longer treat it as a member of the linked list. Neither update contains a loop. Apart from allocation and memory management, the link work is
Use merge sort, stopping before an empty or singleton linked list would be split.
PROCEDURE MergeSort(less: LESS; VAR p: List);
VAR q, r: List;
BEGIN
  IF p.count > 1 THEN
    Split(p, q, r);
    MergeSort(less, q); MergeSort(less, r);
    Merge(less, q, r, p)
  END
END MergeSort;
By induction on the length, each recursive call returns a sorted permutation of its input. Part (d) makes both child lengths smaller than the parent whenever the parent length exceeds one; part (e) combines the sorted children. No data linked list nodes are newly allocated or lost. Unreachable headers may be reclaimed by garbage collection.
At each level the total splitting and merge algorithm work is linear; approximately equal halves give logarithmic depth. Consequently
There are header allocations over the whole execution; those allocations should not be confused with the logarithmic call stack bound.
Constructing channel implementations, decorators and adapters allocates software objects that hold state and references to other software objects. As configurations and temporary processing chains are replaced, some old software objects become unreachable. A typical Scala program on a managed runtime relies on garbage collection to recycle that storage; otherwise unreclaimed allocation can exhaust the available heap memory.
A reachable wrapper keeps its wrapped component reachable. Sharing a channel among several wrappers can extend its lifetime until all relevant references disappear. Many software objects alone do not imply that collection can free them: if the program deliberately retains every channel, those software objects remain live. The reason garbage collection is useful is repeated allocation combined with changing reachability, not an assumption that the integer-returning apply operation allocates a fresh channel on every call.
Garbage collection automatically reclaims allocated memory that is no longer reachable by the running program. Garbage collection roots such as active references and static storage lead through object-reference fields to reachable software objects in heap memory. A tracing garbage collection implementation preserves reachable software objects and can reclaim unreachable ones, including unreachable cycles.
An software object becoming unreachable is different from its state being old or its last object method call having finished. A retained reference can keep it live indefinitely. Collection timing is an implementation matter; automatic reclamation does not promise that an software object is reclaimed immediately when the final useful reference disappears.
Use the trait and node definition above. The reference to a “stack” in this part is a wording error: the declared class and operations implement a FIFO queue.
class ListQueue extends Queue[Int] {
  private var first: QueueNode = null
  private var last: QueueNode = null
  private var size = 0

  def enqueue(x: Int): Unit = {
    require(size < Int.MaxValue, "queue size limit")
    val fresh = new QueueNode(x, null)
    if (last == null) first = fresh
    else last.next = fresh
    last = fresh
    size += 1
  }

  def dequeue(): Int = {
    require(first != null, "empty queue")
    val answer = first.value
    first = first.next
    size -= 1
    if (first == null) last = null
    answer
  }

  def clear(): Unit = {
    first = null
    last = null
    size = 0
  }

  def isEmpty: Boolean = size == 0
  def length: Int = size
}
Appending links the fresh node after the old tail, or establishes both endpoints when empty. Removing the head preserves the tail unless the final node was removed, in which case both endpoints become null. Clearing only discards the endpoint references; it need not visit or overwrite unreachable nodes. Thus all operations are in the usual pointer-operation/allocation cost model, with later garbage collection excluded from an individual operation's bound. The representation invariant and abstraction function show the specified sequence changes, including empty/singleton transitions.
Pinned memory object 2026-11-05
A pinned memory object is a normally movable memory object whose address must remain unchanged during a specified operation. Pinning permits a pointer to remain usable when the code consuming it cannot participate in the runtime's relocation of references. The pinning lifetime is part of that guarantee: an address retained beyond the protected operation need not remain valid. Microsoft's language reference specifies that a fixed statement prevents relocation during its body and restricts the declared pointer to that statement.[ref]
For an original layout example, consider96 bytes with a pinned16-byte object at offsets and one other16-byte live object. The remaining64 bytes are free. Even if the other object can move anywhere, the pinned object divides the address range into regions of32 and48 bytes. A56-byte contiguous allocation cannot fit. Moving the other object into gives free intervals and , whose largest size is48 bytes. If both live objects could move, placing them in would instead leave a64-byte interval. Pinning can therefore limit memory compaction despite ample total free capacity.
The numerical layout omits allocation headers and memory alignment; a real allocator must include them. Pinning an object's address also does not by itself specify how its virtual memory pages are backed. The garbage collector's object-relocation guarantee and an operating system's physical-page residency rules concern different layers. Likewise, a pinned buffer in a storage cache may mean protection from eviction rather than this object-relocation guarantee.
Once the protected operation is finished, releasing its pin can restore the runtime's freedom to move the object during a later collection. The program still has to obey the language's reference-lifetime rules: releasing a pin does not convert an old unmanaged address into a relocatable reference. The general garbage collection process must update references when it moves surviving objects.[ref]