0%

s22 — Dev-Mode Tier: ori run / ori test on the Native Fast Tier

Goal

The fast tier becomes the development execution path: ori run --backend=native and ori test --backend=native are first-class, with function-granular backend reuse, parallel compilation as well as parallel execution, and the s03-decided quick-AOT/in-memory shape chosen by measured edit-to-output latency rather than implementation convenience.

Implementation Sketch

  • Execution shape per the s03 decision record: quick-AOT (cached fragments -> deterministic object/partitions -> link -> exec) vs in-memory emission (map cached function fragments + resolve runtime symbols in-process). Implement the selected shape and re-open the recorded escalation only if s17B telemetry shows finalization/link prevents the edit-to-output gate; a high backend cache-hit rate with a slow relink is not success.
  • ori run: single-file + multi-file paths through ExecutionBackend::Compiled(CodegenBackendChoice::Native) over the one realization/layout/codegen boundary; stdout/exit-code parity with ori build+exec pinned.
  • ori test: the s04 AOT-shaped runner goes production-grade — batch discovery, s17B parallel compilation of cache misses, deterministic finalization, then parallel execution (no LLVM Context lock), with stable result aggregation and native compile-failure classification. Compilation and execution timings remain separate so one cannot hide the other.
  • Salsa/caching integration: consume cached upstream realization/borrow outputs while the backend’s content-addressed CompiledFunctionFragment cache remains independent and function-granular. Serde-skipped derived fields recompute before keying; no Salsa dependency enters ori_backend. The current LLVM-private module-keyed caches are neither reused nor treated as proof of native incrementality.
  • Dev-loop matrix: cold run, warm no-change, one-function body edit, ABI/layout edit, typed-fact edit, and test-suite edit under jobs=1/N. Record frontend, backend, finalization/link, startup, and execution separately; the unchanged-backend-invocation and exact-closure gates from s17B remain hard requirements here.
  • Dev ergonomics: ORI_BACKEND env default honored; error surfaces identical to LLVM path.

Test Strategy

  • Matrix: {run single-file, run multi-file, test small suite, test full spec dir} x {cold,warm,body-edit,contract-edit} x {jobs=1,N} — evaluator/VM/LLVM/native parity plus compile/artifact/diagnostic/result determinism.
  • Semantic pin: edit-to-output latency ledger vs the current LLVM development path, with backend work, finalization/link, and execution broken out and every ratio /calc-verified.
  • Negative pins: stale derived facts, omitted key dependency, corrupt fragment, and shuffled worker completion are recomputed/rejected/stably ordered; a deliberately slow relink prevents the dev-loop row from passing.

Work Items

  • Quick-AOT/in-memory execution-shape implementation per s03 decision + measured cold/warm/edit comparison including finalization/link before lock-in or evidence-triggered escalation.
  • ori run native path (single + multi-file) with build/exec parity pins.
  • ori test native runner production-grade: batch discovery, function-cache lookup, parallel compilation of misses, deterministic finalization, parallel execution, summary integration, and native compile-failure classification.
  • Upstream-cache + function-fragment-cache integration with exact invalidation, derived-field recompute, corruption/version handling, and poisoned/omitted-key negative pins.
  • Cold/warm/body-edit/contract-edit latency ledger vs the LLVM development path recorded with frontend/backend/finalize-link/startup/exec decomposition.