Speed and Memory Grind to LuaJIT Interpreter Class
Goal
Optimize the correct VM to co-equal north-star completion gates: at least as fast as and no more memory-hungry than a pinned LuaJIT -joff interpreter on equivalent output-checked programs. At least 2× faster than frozen Python 3 and at most half its workload-attributable peak memory per program and by corpus geometric mean are the bottom bars for a viable prototype, not the destination; unadjusted peak RSS must also be no worse than Python.
Implementation Sketch
- Lock toolchain, CPU/governor metadata, comparator revisions, command lines, outputs, warmups, and noise policy before tuning. Report process-startup and steady-state results separately.
- Tune one measured lever per ledger cycle: opcode mix/fusion, dispatch shape, register allocation, frame reuse, constant access, built-in/runtime-call overhead, branch layout, safe slot representation, allocation traffic, working-set layout, and metadata/code footprint. Record speed and memory together.
- Test storage specialization before semantic specialization: select canonical versus validated physical layout once at session entry, monomorphize only the operand/frame-access policy, and retain one opcode-handler implementation. Count text size and build time so duplicated machine code cannot masquerade as a free dispatch win.
- Admit a portable tracelet only from verifier-proved canonical regions. Every tracelet carries an ordered canonical expansion, exact PC/fuel/profile progress, fallibility/effect boundaries, state roots, and frozen AIMS event identities; probes, insufficient fuel, or an exceptional boundary execute the exact canonical prefix. Region recognition is structural and typed, never keyed by benchmark, function, or source spelling.
- A fused or specialized opcode must expand to the same ARC/ownership trace. The VM may reduce interpreter overhead around RC operations; it may not omit or relocate AIMS policy.
- Require absolute evaluator/VM/LLVM debug/release/AOT behavior parity, final-live-zero, bounded-growth, and memory-floor gates on every kept result. Any mismatch or leak invalidates the reading and the change is reverted or fixed before measurement continues. Record kept, reverted, inert, and explicit Pareto-tradeoff outcomes with before/after timing, RSS, managed-byte/object, allocation, frame, bytecode, and tier-state evidence.
- Use predeclared cycle/time budgets to control each iteration and force profiler-backed reassessment. Budget exhaustion may pause a run and produce a gap decomposition, but it does not satisfy, re-scope, or close the plan. The 2× Python gate is the hard bottom bar; pinned LuaJIT
-joffremains the completion target. - Grind against a frozen breadth matrix, not a single hot loop: semantic slices plus combined application-shaped programs, multiple input/working-set/nesting scales, and an existing-fixture applicability sweep. Require the Python floor per program as well as by geometric mean so a fast kernel cannot mask collapse under mixed semantics.
- Maintain two explicit lanes. The strict-interpreter lane disables Ori tier-up and compares only with pinned LuaJIT
-joff; it alone can satisfy the interpreter north star. The tiered lane prototypes quickening, portable regions, native method/region/trace JIT, OSR, and deoptimization against separately labeled LuaJIT JIT-on and other appropriate controls. Tiered results neither replace nor contaminate interpreter-only readings, but JIT remains fully in scope for the final unified eval architecture.
Layer Coverage
| Layer | Disposition |
|---|---|
| L1 | N/A: VM tuning changes no grammar. |
| L2 | N/A: VM tuning changes no typechecking. |
| L3 | N/A: VM tuning changes no canonicalization. |
| L4 | N/A: the VM must preserve the already-proven ARC/ownership trace; tuning cannot change AIMS policy. |
| L5 | Covered by the output-checked interpreter performance criterion. |
| L6 | N/A: VM-local tuning does not change LLVM debug. |
| L7 | N/A: VM-local tuning does not change LLVM release. |
| L8 | N/A: VM-local tuning does not change AOT. |
| L9 | Covered by the section cross-executor criterion for every kept change. |
| L10 | Covered by the section leak-freedom criterion for every kept change. |
| L11 | Covered by the tuned-corpus spec/behavior criterion. |
| L12 | Covered by the real ori run --backend=vm LuaJIT-comparator criterion. |
Work Items
- Tune dispatch, opcode mix, frames, and call paths through one-change ledger cycles with profiler evidence, parity, final-live-zero gates, speed/memory scale sweeps, and combined-application interaction measurements.
- Tune safe slot/value, constant, collection/COW, runtime-call, allocation, working-set, and bytecode/metadata overhead without changing AIMS operation placement; retain only speed-and-memory dispositions that survive the frozen semantic slices and application corpus.
- Run the staged production gates (at least 2× faster and 2× lower workload-attributable peak memory than Python 3 for every program and by geometric mean, unadjusted RSS no worse than Python, then pinned LuaJIT
-joffspeed and memory) and keep the plan open until both north-star targets are satisfied without weakening parity, safety, workload breadth, or either resource criterion. Report the separate tiered/JIT lane and its code/metadata/state footprint throughout.