ADR-0009: RC Fallback and Cycle Policy
Status: accepted
Date: 2026-07-25
Context
The current runtime uses shared RC and cannot reclaim strong cycles. The target memory model is region-first, but unresolved shared escape still needs a safe, visible fallback during migration.
Options considered
| Option | Benefit | Cost |
|---|---|---|
| Hidden tracing GC | Handles cycles | Violates North Star and adds hidden cost |
| Ban RC immediately | Pure target | Blocks migration and general objects |
| Cost-visible RC fallback | Practical and measurable | Cycle restrictions and runtime cost |
Decision
RC may exist as a cost-visible fallback for unresolved acyclic shared escape.
It is not a semantic foundation and is not allowed on an rc_free certified
hot path.
Core-N0 v0.1 permits region-contained cycles and acyclic escaping ownership. General shared escaping strong cycles and weak references are outside v0.1. Safe code cannot construct a general escaping strong cycle in the admitted subset.
No hidden tracing collector is introduced.
Rationale
- Region-contained graphs can be reclaimed in bulk.
- The restriction avoids pretending RC solves cycles.
- Visible RC allows profiles and proofs to drive elimination.
- Deferring
Weakavoids making reclamation timing observable too early.
Trade-offs
- Some graph shapes are initially rejected or remain outside safe Core.
- RC traffic can still hurt non-certified generic paths.
Consequences
Allocation reports expose RC operations. A hot-path certificate includes an
rc_free assertion checked against residual Core/SSA and runtime telemetry.
Revisit trigger
Weak references require a new ADR defining upgrade observability, reclamation timing, concurrency interaction, and specialization behavior.