KarpelesLab / goro / 25322649549

13%

Build Type

push

github

Committed by MagicalTux

Commit Message

vm: dispatch closure bodies through the bytecode VM

Closure bodies (top-level functions, anonymous closures,
arrow fns) now optionally compile to bytecode and dispatch
through the VM instead of the AST tree-walker.

Wiring:
- New core/vm/ClosureBody wraps a *vm.Function as a Runnable
  that translates an OpRet result into a *phperr.PhpReturn
  error so ZClosure.callBody picks it up via CatchReturn —
  zero changes to the existing return / exception flow.
- core/compiler/vmaccess.go exposes two hook variables
  (TryBuildVMClosureBody, TryBuildVMScript) plus a public
  IsVMCompiled helper for tests.
- core/vm/vmcompiler/register.go installs both hooks at init
  and reads GORO_VM=1 to gate them. SetEnabled(bool) lets
  tests/benchmarks toggle at runtime.
- All five SAPIs blank-import the vmcompiler package so the
  hooks are registered.
- collectStaticVars unwraps ClosureBody.Inner() so static-var
  collection still works (it would no-op anyway today since
  static-var-using bodies fall back to AST).

Bench impact (vs. AST-only baseline, per-iter):
  Fibonacci (recursion-heavy):  -20% CPU  (27.3M -> 21.1M ns)
  Arithmetic (binop-heavy):     -20% CPU  (43.8M -> 35.1M ns)
  FunctionCalls:                flat
  ArrayOps:                     -5% CPU  (foreach falls back)
  StringConcat:                 flat
The Fibonacci win comes from OpRet returning the value
directly — no per-call PhpReturn allocation. Arithmetic
benefits from the tight loop dispatch staying in one Go frame.

Allocs are slightly higher under VM in two benches; the VM's
stack scratch buffer is the main cause. A pool for those
buffers is a follow-up.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Coverage Stats

60 of 82 new or added lines in 6 files covered. (73.17%)

519 existing lines in 9 files now uncovered.

6582 of 113417 relevant lines covered (5.8%)

642.74 hits per line