Struct ActivationRecord 

#[repr(C)]
pub struct ActivationRecord {
    pub pc: u32,
    pub frame: ArenaRange,
    pub pending_wait: WaitSpecStorage,
    pub fork_state: Option<ForkFrame>,
}

POD, pointer-free, memcpy-checkpointable — the only per-instance execution state that must survive a suspend or a Time-Warp rollback (process.md §3; ledger CG-164, CG-176, ST-005).

Fixed vs. an earlier draft of this contract (caught in review): storing frame: Vec<FrameSlot> / pending_wait: Option<WaitSpec> (its EdgeList variant owns a Vec) / fork_state: Option<ForkFrame> (its child_handles owned a Vec) directly here made the “memcpy- checkpointable” claim false — a Vec is a heap pointer + len + cap, so byte-copying this struct for checkpoint/rollback would duplicate that pointer, and dropping or mutating either copy double-frees or use-after-frees the other. frame: [FrameSlot] in docs/design/process.md’s own struct sketch (§3, line 40) is a DST slice, meaningful only as a reference into memory STATE owns (“owned/allocated by STATE, laid out by this subsystem via FrameLayout”) — never data this struct owns inline. frame below is exactly that reference: an ArenaRange into STATE’s per-process frame arena (word-addressed); the per-slot shape list (FrameLayout/Vec<FrameSlot>) stays a compile-time- only artifact of ProcessLoweringPlan, analogous to state::SlotOffset, and is never embedded in the per-instance runtime record. pending_wait / fork_state are fixed for the same reason — see WaitSpecStorage / ForkFrame’s own doc comments.

Fields

pc: u32

frame: ArenaRange

pending_wait: WaitSpecStorage

fork_state: Option<ForkFrame>

Trait Implementations

impl Clone for ActivationRecord

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for ActivationRecord

impl Debug for ActivationRecord

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.