# Memory and Lifetime - Agenda

Status: Working agenda (pre-spec)  
Purpose: define the authoritative PBS memory, ownership, and lifetime model for v1

## 1. Context

PBS no longer exposes the old RC/HIP syntax as active core language, but the language still needs a precise memory story.
That story must explain:

- what values live on the VM heap,
- what identity and aliasing mean,
- how baseline GC interacts with deterministic execution,
- where host-owned memory begins and ends,
- how allocation and copy costs become visible to advanced users.

Without this agenda, the future `Memory and Lifetime Specification.md` would not have a stable scope.

## 2. Decisions to Produce

This agenda must end with decisions for:

1. The value-category map: stack-like transient values, heap-backed values, callbacks, collections, and host-backed handles.
2. The lifetime and reachability model under baseline GC.
3. The VM heap vs host-memory boundary and the user-visible rules at that boundary.
4. The minimum cost/allocation visibility contract needed by diagnostics and profiling.
5. The migration and reservation policy for legacy RC/HIP concepts.

## 3. Core Questions

### Q1. Heap residency by value category

- Which core values are heap-backed in v1: structs, callbacks, collections, tuples, `optional`, `result`, or only some of them?
- When a value is assigned, passed, or returned, what is copied versus what aliases the same heap identity?

### Q2. Identity and aliasing

- Which user-visible value kinds have stable identity?
- Are struct values always reference-like at runtime even when their fields are small and copyable?
- How should aliasing be described for beginner-facing semantics without hiding performance consequences?

### Q3. Baseline GC contract

- Which GC properties are normative: reachability, eventual reclamation, safepoints, no user finalizers?
- Which GC timing details remain non-normative implementation choices?
- Can user code observe reclamation directly, or only via indirect performance/diagnostic signals?

### Q4. Host memory boundary

- How are host-backed resources represented in PBS user space: opaque handles, nominal structs, services, or reserved host-bound values?
- Can host memory outlive PBS references, and if yes, what runtime contract prevents unsoundness?
- Is pinning, borrowing, or zero-copy transfer exposed in v1 at all?

### Q5. Allocation visibility

- Which operations are allowed to allocate on the VM heap?
- Which host calls may allocate host memory or retain VM-reachable references?
- What must tooling report as allocation, retention, copy, or escape risk?

### Q6. Lifetime-related traps and safety

- Which memory problems are impossible by construction in v1 core?
- Which remaining failures become traps, capability rejection, or host-defined status outcomes?

### Q7. Future explicit control

- Should pools, arenas, object reuse, or weak-reference patterns exist only as stdlib/tooling surfaces?
- What criteria must be met before reserved keywords like `alloc`, `borrow`, `take`, or `weak` can become active in a future profile?

## 4. Expected Spec Material

After discussion, this agenda should directly feed sections of `Memory and Lifetime Specification.md` covering:

1. runtime memory spaces,
2. value representation classes,
3. identity, aliasing, and copy rules,
4. GC and safepoint guarantees,
5. host-memory boundary rules,
6. cost visibility hooks for `Diagnostics Specification.md`.

## 5. Non-Goals

- Defining exact GC algorithm internals.
- Designing complete stdlib pool/arena APIs.
- Reintroducing mandatory user-authored lifetime syntax in core v1.

## 6. Inputs

- `1. Language Charter.md`
- `3. Core Syntax Specification.md`
- `4. Static Semantics Specification.md`
- `Heap Model - Agenda.md`
- `Dynamic Semantics - Execution Model Agenda.md`
- `Dynamic Semantics - Effect Surfaces Agenda.md`