95 lines
3.8 KiB
Markdown
95 lines
3.8 KiB
Markdown
# 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`
|