prometeu-studio/docs/agendas/Memory and Lifetime - Agenda.md

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