[SPIKE] Compile the updating pass to a static plan per template - #21616

A counter, before and after

<button {{on "click" this.increment}}>Count: {{this.count}}</button>

The wire format is unchanged by this PR:

[[[11,"button"],[4,[38,1],["click",[30,0,["increment"]]],null],[12],[1,"Count: "],[1,[30,0,["count"]]],[13]],[],["button","on"]]

Before

The append pass builds the structure of the updating pass at render time, once per instance, as a list of objects. UpdatingVM walks it with a frame stack and one virtual evaluate call per entry.

[
  UpdateModifierOpcode { lastUpdated: 1, tag, modifier },          // {{on}}
  TryOpcode {                                                     // {{this.count}}: the stdlib append switch
    state: Closure { pc, scope, dynamicScope, stack },
    bounds: ResettableBlockImpl,
    children: [
      AssertFilter { last: 2, ref },                              // 2 = ContentType.String
      DynamicTextContent { node, reference, lastValue: "0" },
    ],
  },
]

After

Everything below is dumped from a browser run of the integration tests at 6b0903d, with JSON.stringify on the real objects (object-valued fields shown as <ClassName>, undefined slots as null).

The compiler turns the wire format into these 19 instructions. Three of them can record an updating opcode, and each of those gets a slot index in a side table keyed by instruction address:

addr  instruction                     slot
 0    PutComponentOperations
 1    OpenElement "button"
 3    PushFrame
 4    Primitive
 6    PrimitiveReference
 7    GetVariable 0
 9    GetProperty "increment"
11    PushArgs
15    Modifier on                     0
17    PopFrame
18    FlushElement                    1
19    Text "Count: "
21    PushFrame
22    GetVariable 0
24    GetProperty "count"
26    InvokeStatic cautious-append    2
28    PopFrame
29    CloseElement
30    Return

The plan stored for the counter's handle. Kinds: 1 leaf, 2 multi, 3 guard, 4 guard-end, 5 block, 6 list, 7 call.

{ "kinds": [2, 2, 7], "children": [null, null, null], "links": [-1, -1, -1], "size": 3 }

The plan stored for the stdlib cautious-append routine, which the counter calls at address 26. Its Enter opens a block, and the block has one slot per content-type clause; links pairs the guard at 6 with its end at 11:

{
  "kinds": [5],
  "children": [
    {
      "kinds": [1, 1, 1, 1, 7, 1, 3, 1, 2, 7, 2, 4, 1],
      "children": [null, null, null, null, null, null, null, null, null, null, null, null, null],
      "links": [-1, -1, -1, -1, -1, -1, 11, -1, -1, -1, -1, 6, -1],
      "size": 13
    }
  ],
  "links": [-1],
  "size": 1
}

The root instance after the first render. An instance is { plan, slots }; the append pass wrote each recorded opcode into the slot of the instruction that ran:

{
  "plan": { "kinds": [2, 2, 7], "children": [null, null, null], "links": [-1, -1, -1], "size": 3 },
  "slots": [
    [
      { "$class": "UpdateModifierOpcode", "lastUpdated": 1, "tag": "<MonomorphicTagImpl>", "modifier": "<Object>" }
    ],
    null,
    {
      "plan": { "kinds": [5], "children": ["<the 13-slot block plan above>"], "links": [-1], "size": 1 },
      "slots": [
        {
          "$class": "TryOpcode",
          "type": "try",
          "state": "<Closure>",
          "bounds": "<ResettableBlockImpl>",
          "plan": "<the 13-slot block plan above>",
          "slots": [
            { "$class": "AssertFilter", "last": 2, "ref": "<ReferenceImpl>" },
            null, null, null, null, null, null, null, null, null, null, null,
            { "$class": "DynamicTextContent", "node": "<Text>", "reference": "<ReferenceImpl>", "lastValue": "0" }
          ]
        }
      ]
    }
  ]
}

Slot 1 is empty because FlushElement only records component attributes and there are none. In the block, the 11 empty slots are the clauses for node, fragment, safe string, helper, and component content, which a string never takes. The updating pass is one loop over kinds with a switch; the frame stack, goto, try, and throw are gone.

Spike. Not for merge as is.

What this does

The opcode compiler derives the structure of the updating pass while it emits bytecode. Every instruction whose handler can record an updating opcode gets a slot in an update plan. Enter, EnterList, and the four call instructions open nested plans. The program heap keeps a side table from instruction address to slot index, and one plan per handle.

A render instance is the plan plus a slot array of the same length. The append pass writes each recorded opcode into the slot its instruction owns. The updating pass is one loop over the plan with a switch on the slot kind.

Removed from the runtime: the UpdatingVM frame stack, goto, try, throw, and the JumpIfNotModified, BeginTrackFrame, and EndTrackFrame opcode classes.

A slot stays empty when its instruction recorded nothing: a constant reference, an untaken branch, or a debug-only opcode in production. Instructions whose emission count depends on runtime data (component attribute flushes, modifiers, debug render tree nodes) own one array slot.

The test file packages/@glimmer-workspace/integration-tests/test/update-plan-test.ts prints the plan of a few templates and the slots of a rendered instance. A rendered <div class={{this.cls}}>{{this.name}}</div>{{#if this.a}}{{this.b}}{{/if}} reads as:

[leaf call[block[leaf - - - - - - - - - - - leaf]] block[leaf call[call[block[leaf - - - - - - - - - - - leaf]]]]]

Open points

• The plan builder ships with the JIT compiler, so the bundle grows by 2.5 kB raw and 0.7 kB gzip. Under an AOT compile it moves to build time.
• Untaken branches are holes. The stdlib append routine has 13 slots and a plain text append fills 2. Per-clause sub-plans selected by the taken branch would remove those checks.
• The {{#each}} body needs a new compiler marker (EndItem), because the Exit at FINALLY closes both an item and the outer block.

rere-benchmark

Base bdb2580255 vs 8c2814f96e, mirrored rounds (base, plan, plan, base), cpu throttle 8. The third commit only changes memory use.

js-framework-benchmark

Base bdb2580255 vs 7e9a9efd93. The first run with 8c2814f96e showed ready memory up 4 MB from an eagerly sized slot table; the third commit fixes that, and this table is the rerun. The first-paint row is a single sample and moves 20% between runs of identical code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GhCsx9qptiMuhjjeovJzPf