perf: reduce apply() bytecode size (Phase 1 + 2: TempLocalCountVisitor, buffer 256→32, TAILCALL trampoline extraction)

[fglock]

Summary

Reduces the bytecode size of JVM-compiled apply() methods, targeting
the C1 JIT failure ("out of virtual registers in linear scan") that causes
t/96_is_deteministic_value.t (DBIx::Class) to time out under CPU pressure.

Phase 1 — Extend TempLocalCountVisitor + reduce null-init buffer 256→32

Every apply() method begins with a null-initialisation prologue for all
local variable slots. The pre-init count was previously estimated with a
fixed +256 safety margin; this replaces it with a precise count:

• Sub call operator (: +1 (callContextSlot)
• eval/evalbytes: +4 (evalResultSlot, cfSlot, labelSlot, typeSlot)
• for/foreach (For1Node): +4 (preEvalListLocal, iteratorIndex, 2 conditional)
• while/for (For3Node): +1 (conservative)
• Flip-flop ../...: +3 (flipFlopIdSlot, leftSlot, rightSlot)
• xor/^^: +1 (leftVar)

Buffer reduced from +256 to +32. Result: ~56% total bytecode reduction
for the DBIx::Class workload.

Phase 2 — Extract per-call-site TAILCALL trampoline to resolveTailCalls()

Every sub call site previously emitted an ~83-byte inline TAILCALL trampoline
to handle goto &sub chains. This adds RuntimeCode.resolveTailCalls() as a
static helper and moves the trampoline logic there.

Key design: resolveTailCalls() is called only inside the
isNonLocalGoto()==true branch, so the common path (no control flow)
has zero extra overhead vs Phase 1 — it remains:

apply(...)  →  ASTORE  →  ALOAD  →  isNonLocalGoto()  →  IFEQ (branch taken)

Per-call-site bytecode: ~83 bytes → ~38 bytes (saves ~45 bytes per site).
A method with 20 call sites shrinks by ~900 bytes; large SQL-generation
closures with 100+ call sites shrink by several KB.

Phase 2 bugfix — Eliminate VerifyError from int-typed callContextSlot

After Phase 2 landed, DBIx::Class t/multi_create/torture.t failed with
"You tried to plan twice". Root cause:

• callContextSlot was allocated via allocateLocalVariable() and stored
  with ISTORE (int type) in EmitSubroutine, Dereference, and
  EmitOperator.
• The pre-init loop initialises every temp slot as ACONST_NULL/ASTORE
  (reference type). At blockDispatcher merge points the JVM verifier saw
  "int vs null-reference" and threw VerifyError: Bad local variable type.
• The VerifyError was caught by executeCodeImpl, which silently fell back
  to the interpreter — re-executing the script body and calling
  plan tests => 23 a second time.

Fix: replace every ISTORE/ILOAD callContextSlot with inline
pushCallContext() at each use site. The -> and ( entries in
TempLocalCountVisitor are kept (they control the pre-init range for
reference spill slots — removing them caused a second VerifyError at a
different slot).

Post-rebase fix — Restore correct tied-scalar FETCH count for fallback compound assigns

The Phase 2 changes exposed a pre-existing bug in the fallback path of
handleCompoundAssignment() (used for |=, &=, ^=, **=, <<=, >>=, .=).
For tied scalar lvalues, Perl semantics require two FETCHes on compound
assignment (one to read the current value, one to return the result). The
fallback path was returning set()'s return value — a plain scalar copy from
tiedStore() — instead of the lvalue itself, so the 2nd FETCH never fired.

Before Phase 2 this accidentally passed in op/bop.t because the tied object
was unwrapped later by a toString() call inside is(). Phase 2 changed
argument passing so that path no longer triggered, exposing the bug as 9 new
test failures (491/522 vs baseline 500/522).

Fix: keep leftSlot live across the set() call, discard set()'s return
value, then reload leftSlot — matching how addAssign, subtractAssign, etc.
already return arg1 directly. Result: op/bop.t 500/522 (baseline restored).

Files changed

File	Change
TempLocalCountVisitor.java	Extended to count 6 new local-allocating patterns; kept -> and ( entries as pre-init range proxies
EmitterMethodCreator.java	Buffer: +256 → +32
RuntimeCode.java	New resolveTailCalls(RuntimeList, int) static helper
EmitSubroutine.java	Removed inline TAILCALL trampoline; removed callContextSlot allocation
Dereference.java	Removed callContextSlot allocation; inline pushCallContext()
EmitOperator.java	Removed callContextSlot allocation; inline pushCallContext()
EmitBinaryOperator.java	Fallback compound-assign returns lvalue (not set() result) for correct tied-scalar FETCH semantics
dev/design/reduce-apply-bytecode.md	Design doc + progress tracking

Test plan

• make — all unit tests pass (after rebase onto master)
• tail_calls.t — 7/7 (goto &sub factorial, multi-hop chains, @_ aliasing)
• subroutine.t — 39/39
• t/multi_create/torture.t — 23/23 (was failing with "plan twice" before bugfix)
• op/bop.t — 500/522 (baseline restored; 9 tied-scalar compound-assign tests fixed)
• Full DBIx::Class 0.082844 suite — 13,858/13,858 PASS (at commit 3a1707b56)
• Both JVM and --interpreter backends
• LAST/NEXT/REDO after tail-called sub return

Note on t/cdbi/68-inflate_has_a.t CI timeout

This test timed out (exit 137, 300 s) in one CI run "under load". It is not
a regression: the test passes in <60 s locally on the current HEAD (all 6
subtests pass), and the full DBIx::Class suite PASS recorded at 3a1707b56
includes this test. The timeout is load-induced — competing JVMs delay JIT
compilation of DateTime (a large module loaded by this test) past the 300 s
harness limit, the same mechanism documented in dev/design/reduce-apply-bytecode.md.

Generated with Devin

Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>

[fglock]

Phase 4 added: method-size threshold for eval-generated code

Commit a2079f9d6 adds Phase 4 — the key fix for load-induced timeouts.

Problem recap

After Phases 1+2, 7 methods generated by Sub::Quote / Moo via string eval are still 9–36 KB. Under CPU pressure, C1 JIT either fails to compile them efficiently or triggers ASM frame-compute crashes, causing t/cdbi/68-inflate_has_a.t to time out at the 300 s harness limit.

Phase 4 approach

Add a method-size threshold check after bytecode generation in EmitterMethodCreator.getBytecodeInternal():

• Parse the generated class file to find the largest method's code length
• If the code is eval-generated (fileName starts with "(eval ") and the largest method exceeds JPERL_MAX_METHOD_BYTES (default: 9,000 bytes), throw a RuntimeException with "requires interpreter fallback" in the message
• createRuntimeCode() catches this and routes to the PerlOnJava interpreter
• Fast path: if classData.length <= threshold, skip parsing (99% of classes are small)

Why eval-only?

Regular Perl files can also have methods up to ~16 KB (e.g. unit test bodies in local.t) that work correctly on the JVM backend but would fail on the interpreter due to known parity gaps. The C1 failure problem exists exclusively in Sub::Quote string-eval'd code, so restricting the threshold to eval-generated code avoids false positives.

Results

make: all unit tests PASS
t/cdbi/68-inflate_has_a.t: PASS 6/6
  Phase 4 fires for 3 Sub::Quote methods:
    - 14,392 bytes
    - 13,449 bytes  
    - 15,668 bytes

The default threshold (9,000 bytes) catches all 7 Sub::Quote/Moo methods (minimum 9,043 bytes) while leaving all regular user-code methods on the fast JVM path.

Env vars

Var	Effect
JPERL_MAX_METHOD_BYTES=N	Override threshold (set to large number like 999999 to disable)
JPERL_SHOW_FALLBACK=1	Shows "Method too large for reliable JIT: N bytes" when threshold fires
JPERL_BYTECODE_SIZE_DEBUG=1	Shows all method sizes + threshold actions

[fglock]

./jcpan -t DBIx::Class pass