Optimize control flow with block-level dispatcher sharing

[fglock]

Summary

Implements block-level dispatcher sharing to eliminate redundant control flow dispatch code when multiple calls occur in the same block with the same visible loops.

The Problem

Previously, each call site emitted a complete control flow dispatcher (~150 bytes):

for (1..3) {
    A();  # 150 bytes dispatcher
    B();  # 150 bytes dispatcher (identical!)
    C();  # 150 bytes dispatcher (identical!)
    D();  # 150 bytes dispatcher (identical!)
}

Total: 600 bytes of redundant code for 4 calls.

The Solution

Block-level shared dispatchers - all calls with the same visible loop state share ONE dispatcher:

• Call sites: Simple check (~20 bytes) + GOTO to shared dispatcher
• Block dispatcher: Full dispatch logic (~150 bytes, emitted once)
• Automatic reuse: Signature-based matching via blockDispatcherLabels map

Results

Bytecode Savings

Calls	Old (bytes)	New (bytes)	Savings	Percentage
1	150	173	-23	-15%
2	300	193	107	36% ✅
4	600	233	367	61% ✅
10	1500	353	1147	76% ✅

Real-World Measurements

• Test with 4 sequential calls: 2232 → 2139 bytecode lines (4.2% reduction)
• CHECKCAST operations: 23 → 17 (26% reduction)
• Complex nested loops: No regression (1374 lines maintained)
• All 2006 unit tests pass ✅

Implementation Details

Modified Files

1. JavaClassInfo.java

   • Added blockDispatcherLabels map to track dispatcher reuse
   • Added getLoopStateSignature() method for unique loop state identification
   • Uses identity hash codes to distinguish loop instances

2. EmitSubroutine.java

   • Simplified call-site emission to ~20 bytes (check + GOTO)
   • Added emitBlockDispatcher() helper method
   • First call with a signature creates and emits dispatcher
   • Subsequent calls with same signature reuse existing dispatcher

3. Documentation

   • New: BLOCK_DISPATCHER_OPTIMIZATION.md - detailed optimization guide
   • New: CONTROL_FLOW_IMPLEMENTATION.md - comprehensive implementation guide
   • Removed: 6 obsolete design docs

How It Works

1. Compute loop state signature (visible loop labels + identity hashes)
2. Check if dispatcher exists for that signature in blockDispatcherLabels
3. If first use: create dispatcher label, emit dispatcher code after call site
4. If reuse: jump to existing dispatcher label
5. Dispatcher stays within loop scope (no frame computation issues)

Trade-offs

Advantages:

• ✅ Massive savings for multiple calls (61% for 4 calls)
• ✅ Common pattern in real Perl code
• ✅ No frame computation issues
• ✅ Automatic optimization

Disadvantages:

• ⚠️ 23 bytes overhead for single calls (acceptable)
• Small HashMap overhead per method

Net Result: Overall WIN for typical Perl code patterns.

Testing

All 2006 unit tests pass, including:

• ✅ Control flow tests (last/next/redo)
• ✅ Non-local control flow
• ✅ Tail call optimization
• ✅ Nested loops
• ✅ Labeled control flow
• ✅ Complex real-world code

Why This Works Better Than Alternatives

vs. Per-Call Dispatchers (Previous)

• Eliminates redundancy while maintaining correctness
• 36-76% savings for multi-call blocks

vs. Method-Level Centralization (Attempted)

• Stays within loop scope (no frame errors)
• Only checks visible loops (not all method loops)
• Actually reduces bytecode (centralization increased it)

Block-level is the sweet spot: sharing within proper scope boundaries.

🤖 Generated with Claude Code