Wasm: dispose per-dispatch MessageEvent/Event in worker-response handlers (4.12.1-local.10)

WasmAccelerator.EnsurePersistentHandlers installs persistent per-worker
OnMessage/OnError handlers. Each worker response delivers a MessageEvent
(and each error an Event) JSObject that the handler OWNS - SpawnDev.BlazorJS
does not auto-dispose an ActionEvent handler's argument (ActionCallback<T1>.Invoke
calls the delegate and never disposes the arg; confirmed by the library author).

The handlers never disposed msg/err, so every (dispatch x worker) response left a
MessageEvent reclaimable only by the finalizer (disposal-breakdown over a TurboQuant
lane: MessageEvent created=9971, proper=0, finalizer=9969). Between GCs this transient
pile-up spikes the main-thread V8 heap during a heavy dispatch storm - the likely
trigger of the ML late-lane heavy-test timeouts.

Fix: `using` the MessageEvent/Event arg in both handlers so each disposes
deterministically on every path (including the stray-message early return).
WasmDispatchResponse is a plain DTO, so it stays valid after msg is disposed.

Also: corrected the WasmMemoryBuffer header comment (data buffers are staged through
the shared linear memory on the main thread, NOT zero-copy shared to workers - the
inaccurate line had seeded a worker-pinned-SAB hypothesis).

Guard: WasmTests.Wasm_DispatchResponse_DoesNotLeakMessageEvent (alive-MessageEvent
count via BlazorJS IDisposableTracker, kept off the tracker's Console/verbose paths).

NOTE: a separate, slower persistent retained-object climb (non-MessageEvent,
main-thread V8) remains under investigation via a CDP bytes-by-type + retainers heap
snapshot - tracked, distinct from this transient fix.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: LostBeard

CHANGELOG.md

@@ -13,6 +13,7 @@ Wrapper-only (forks stay **2.0.16**). Adds a new selection-gate capability flag:
 - **Wasm SIMD128 emitter foundation (Phase 1 of the SIMD port).** Additive groundwork only - no production kernel emits v128 yet, so the scalar path is byte-identical. Adds the v128 value type and the 0xFD-prefixed SIMD opcode set to `WasmOpCodes` (spec-verified; sub-opcodes are u32-LEB128 after the prefix, so multi-byte ones like `f32x4.add`=228 encode correctly), v128 emit helpers in `WasmModuleBuilder` (`EmitSimd`/`EmitSimdMem`/`EmitSimdLane`/`EmitV128Const`/`EmitI8x16Shuffle`), and the runtime SIMD capability surface: `WasmBackend.RuntimeSupportsWasmSimd` (via `System.Runtime.Intrinsics.Wasm.PackedSimd.IsSupported` - if the running Blazor WASM build has SIMD enabled, the browser/workers accept v128), `ForceScalar`/`ForceSimd` test overrides, `EffectiveWasmSimd`, `WasmCapabilityContext.WasmSimd`, and `WasmAccelerator.SupportsSimd`. **Non-SIMD devices stay first-class forever** (the scalar path is a supported mode, not a deprecated fallback - real hardware/browsers without wasm SIMD are common; see the dual-build technique in `BlazorWASMSIMDDetectExample`). Verified by the offline `DemoConsole -- wasm-simd-probe`: a hand-built v128 module is `wasm-validate`-clean and `wasm2wat`-decodes to the intended instructions.
 - **Wasm: bound the persistent-worker module cache (late-lane memory-pressure fix).** The process-persistent worker pool keeps every distinct kernel's compiled `WebAssembly.Module` in a per-worker cache (`_modulesById`) for the tab's life. Across a long test lane each per-test accelerator's kernels get fresh ids, so the cache accumulated unbounded (measured 2 -> 1057 across a ~570-test lane) until late, heavy tests hit process-memory pressure and timed out (the committed shared linear memory was flat/small - the module cache was the driver). Fix: when cumulative kernels compiled since the last flush cross `WasmBackend.ModuleCacheFlushThreshold` (default 256; 0 disables), the host instructs the workers to drop their module/instance caches at the next fresh accelerator's FIRST dispatch (safe - that accelerator re-sends its own kernels; the cleared modules are disposed accelerators' dead weight). Bounds peak modules to ~the threshold. Short workloads never reach it -> never flush -> kernels stay fully warm. Diagnostics `WasmAccelerator.TotalKernelsCompiled` / `SharedWasmMemoryPages`; guard `WasmTests.Wasm_ModuleCacheFlush_DoesNotBreakCorrectness` (flushes every accelerator, asserts CPU-oracle).
 - **Wasm: fixed a host-write SNAPSHOT SharedArrayBuffer leak (the real ML-lane heavy-test memory leak).** `WasmMemoryBuffer.PrepareHostWrite` allocates a full-buffer-size SharedArrayBuffer when a host write lands while a dispatch is in flight on that buffer (the lazy copy-out race defense). `CompleteDispatchIntent` removed the snapshot from its tracking dict but **never `Dispose()`d the SharedArrayBuffer** (despite its own doc claiming "that tier's SAB is freed"), and the all-intents-complete path dropped the dict without disposing either - so every materialized snapshot leaked a full-buffer-size JS SharedArrayBuffer. Under a long heavy-workload lane (ML's CopyFromCPU+dispatch pattern) this accumulated to ~1.5 GiB of JS heap, slowing late tests into timeouts (root-caused via a resident-memory trace: heap 154->1644 MiB; worker pool flat, linear memory flat, module cache flat by magnitude). Fix: dispose the snapshot SAB on release + on buffer dispose (`DisposeAllSnapshots`). New diagnostic `WasmMemoryBuffer.LiveSnapshotBytes`; guard `WasmTests.Wasm_HostWriteSnapshot_DoesNotLeakSAB` (deterministically materializes snapshots, asserts the resident bytes return to baseline). Also adds resident-count diagnostics `WasmMemoryBuffer.LiveBufferCount`/`LiveBufferBytes` + `WasmAccelerator.LiveAcceleratorCount`.
+- **Wasm: dispatch-response handlers now dispose the per-dispatch `MessageEvent`/`Event` JSObject.** `WasmAccelerator.EnsurePersistentHandlers` installs persistent per-worker `OnMessage`/`OnError` handlers; each worker response delivers a `MessageEvent` (and each error an `Event`) JSObject that the handler **owns** - SpawnDev.BlazorJS does not auto-dispose an `ActionEvent` handler's argument (`ActionCallback<T1>.Invoke` calls the delegate and never disposes the arg; confirmed by the library author). The handlers never disposed `msg`/`err`, so every (dispatch x worker) response created a `MessageEvent` that was reclaimed only by the finalizer (disposal-breakdown over a TurboQuant lane: `MessageEvent created=9971, proper=0, finalizer=9969`). Between GCs this transient pile-up spikes the main-thread V8 heap during a heavy dispatch storm - the likely trigger of the late-lane heavy-test timeouts. Fix: `using` the `MessageEvent`/`Event` arg in both handlers so each disposes deterministically on every path (including the stray-message early return). Guard `WasmTests.Wasm_DispatchResponse_DoesNotLeakMessageEvent` (alive-`MessageEvent` count via BlazorJS `IDisposableTracker`, kept off the tracker's verbose/Console paths). NOTE: a separate, slower persistent retained-object climb (non-`MessageEvent`) remains under investigation via a CDP bytes-by-type + retainers heap snapshot - tracked, distinct from this transient fix.
 
 ## 4.12.0 (2026-06-13) - Sync/async contract: async-only where it waits/observes, sync for fire-and-forget
 

SpawnDev.ILGPU.Demo/UnitTests/WasmTests.cs

@@ -1884,6 +1884,80 @@ public async Task Wasm_HostWriteSnapshot_DoesNotLeakSAB()
             finally { accelerator.Dispose(); context.Dispose(); }
         }
 
+        // Wasm per-dispatch MessageEvent leak guard (2026-06-15, Geordi). EnsurePersistentHandlers installs
+        // persistent OnMessage/OnError handlers on each worker; every worker response delivers a MessageEvent
+        // JSObject that the handler OWNS — SpawnDev.BlazorJS ActionCallback<T1>.Invoke calls the delegate and
+        // does NOT dispose the arg (verified ActionCallback.cs:59-63). Before the fix the handler never disposed
+        // msg/err, so every (dispatch x worker) response pinned a MessageEvent (+ its .data graph) in the V8 JS
+        // heap until finalization — which JS-heap growth alone never triggers under a long Wasm lane → the
+        // ~1.6 GiB ML-lane late-test memory-pressure leak (Tuvok CDP). Fix = `using` on msg+err so each disposes
+        // in-handler on every path (incl. the stray-message early return).
+        //
+        // This guard uses BlazorJS IDisposableTracker to count ALIVE MessageEvent JSObjects after N dispatches.
+        // It enables ONLY UndisposedHandleVerboseMode (NOT CreatedHandleVerboseMode) so the tracker's
+        // Console.WriteLine paths — which trip #blazor-error-ui and would false-FAIL the run — never fire: the
+        // created-notice (line 95) is gated on CreatedHandleVerboseMode (kept off), and the finalizer-warning
+        // (line 37) only fires for TRACKED objects disposed via finalizer; with the fix every MessageEvent is
+        // DisposedProper in-handler, and objects created while the flag was off carry a null tracker so their
+        // disposal short-circuits before the Console path. We never force GC inside the measured window.
+        // With the fix: alive MessageEvents ≈ 0. Without it: ≈ dispatches * workerCount (hundreds).
+        [TestMethod(Timeout = 120000)]
+        public async Task Wasm_DispatchResponse_DoesNotLeakMessageEvent()
+        {
+            const int count = 4096;
+            const int dispatches = 40;
+            bool savedUndisposed = SpawnDev.BlazorJS.IDisposableTracker.UndisposedHandleVerboseMode;
+            bool savedCreated = SpawnDev.BlazorJS.IDisposableTracker.CreatedHandleVerboseMode;
+            var context = Context.Create().Wasm().ToContext();
+            var accelerator = await context.CreateWasmAcceleratorAsync();
+            try
+            {
+                // Warm-up dispatch (tracking OFF): installs the persistent handlers + compiles the worker module
+                // so their one-time JSObjects are not in the measured window.
+                using (var warm = accelerator.Allocate1D<int>(count))
+                {
+                    var wk = accelerator.LoadAutoGroupedStreamKernel<Index1D, ArrayView<int>>((i, v) => v[i] = i);
+                    wk((Index1D)count, warm.View);
+                    await accelerator.SynchronizeAsync();
+                }
+
+                // Enable tracking with the Console-safe flag only, then clear for a clean baseline.
+                SpawnDev.BlazorJS.IDisposableTracker.CreatedHandleVerboseMode = false;
+                SpawnDev.BlazorJS.IDisposableTracker.UndisposedHandleVerboseMode = true;
+                SpawnDev.BlazorJS.IDisposableTracker.JSObjectTraces.Clear();
+
+                var k = accelerator.LoadAutoGroupedStreamKernel<Index1D, ArrayView<int>>((i, v) => v[i] = i * 3);
+                for (int r = 0; r < dispatches; r++)
+                {
+                    using var buf = accelerator.Allocate1D<int>(count);
+                    k((Index1D)count, buf.View);
+                    await accelerator.SynchronizeAsync();
+                }
+                // Let any inline TCS continuation unwind so the final handler lambda exits and its `using` disposes.
+                await Task.Yield();
+
+                long aliveMsgEvents = 0;
+                foreach (var t in SpawnDev.BlazorJS.IDisposableTracker.JSObjectTraces.Values)
+                    if (t.Type != null && t.Type.Contains("MessageEvent"))
+                        aliveMsgEvents += t.AliveCount;
+
+                // Fix → ~0 (at most a straggler); bug → dispatches*workerCount (>=160). Bound cleanly separates.
+                const long bound = 8;
+                if (aliveMsgEvents > bound)
+                    throw new Exception(
+                        $"Per-dispatch MessageEvent JSObjects leaked: {aliveMsgEvents} alive after {dispatches} dispatches " +
+                        $"(bound {bound}). WasmAccelerator.EnsurePersistentHandlers must Dispose the MessageEvent/Event " +
+                        $"arg in MsgHandler/ErrHandler on every path (the ML-lane ~1.6 GiB V8-heap leak has regressed).");
+            }
+            finally
+            {
+                SpawnDev.BlazorJS.IDisposableTracker.UndisposedHandleVerboseMode = savedUndisposed;
+                SpawnDev.BlazorJS.IDisposableTracker.CreatedHandleVerboseMode = savedCreated;
+                SpawnDev.BlazorJS.IDisposableTracker.JSObjectTraces.Clear();
+                accelerator.Dispose(); context.Dispose();
+            }
+        }
+
         // Wasm SIMD128 emitter foundation (Phase 1, 2026-06-14, Geordi). Pure-CPU regression guard on
         // the v128 encoding — NO browser/GPU needed, just byte assertions. Locks the part most likely
         // to silently break: SIMD sub-opcodes are u32-LEB128 after the 0xFD prefix (NOT single bytes

SpawnDev.ILGPU/SpawnDev.ILGPU.csproj

@@ -4,9 +4,9 @@
 		<TargetFramework>net10.0</TargetFramework>
 		<ImplicitUsings>enable</ImplicitUsings>
 		<Nullable>enable</Nullable>
-		<Version>4.12.1-local.9</Version>
+		<Version>4.12.1-local.10</Version>
 		<!-- Brief current-version highlights only. Full per-version history with code samples lives in CHANGELOG.md (linked from the README). -->
-		<PackageReleaseNotes>4.12.1: WebGPU cooperative GEMV grid-stride fix; ±inf/NaN scalar kernel params on WebGL+Wasm; AcceleratorRequirements.RequiresScatterStores flag; Wasm process-persistent shared Web Worker pool AND shared linear memory keyed per MaxLinearMemoryPages (default-WorkerCount accelerators share one pool + one WebAssembly.Memory per distinct max per tab, fixing worker-churn starvation and the WebAssembly.Memory-reservation accumulation across long test lanes — at both the default 1 GiB and custom maxes like 2 GiB); Wasm SIMD128 emitter foundation (additive groundwork, scalar path unchanged). Forks stay 2.0.16. Full per-version history with details: CHANGELOG.md at https://github.com/LostBeard/SpawnDev.ILGPU/blob/master/CHANGELOG.md</PackageReleaseNotes>
+		<PackageReleaseNotes>4.12.1: Wasm process-persistent shared worker pool + shared linear memory (per MaxLinearMemoryPages) — fixes worker-churn starvation and WebAssembly.Memory accumulation across long test lanes; Wasm dispatch-response handlers now dispose the per-dispatch MessageEvent/Event JSObject (removes per-dispatch JS-object churn); WebGPU GEMV grid-stride fix; ±inf/NaN scalar kernel params on WebGL+Wasm; AcceleratorRequirements.RequiresScatterStores; Wasm SIMD128 emitter foundation (additive, scalar path unchanged). Forks stay 2.0.16. Full per-version history: CHANGELOG.md at https://github.com/LostBeard/SpawnDev.ILGPU/blob/master/CHANGELOG.md</PackageReleaseNotes>
 		<GeneratePackageOnBuild>True</GeneratePackageOnBuild>
 		<GenerateDocumentationFile>true</GenerateDocumentationFile>
 		<EmbedAllSources>true</EmbedAllSources>

SpawnDev.ILGPU/Wasm/WasmAccelerator.cs

@@ -1869,6 +1869,15 @@ private void EnsurePersistentHandlers(Worker worker)
 
             state.MsgHandler = new Action<MessageEvent>((msg) =>
             {
+                // The MessageEvent JSObject is created per worker-response by the SpawnDev.BlazorJS
+                // callback marshaller and is OWNED by this handler: ActionCallback<T1>.Invoke calls
+                // the delegate and does NOT dispose the arg (verified in SpawnDev.BlazorJS/ActionCallback.cs).
+                // Without disposing it, every (dispatch x worker) response pins a MessageEvent (and its
+                // .data graph) in the V8 JS heap until finalization - which JS-heap growth alone never
+                // triggers under a long Wasm dispatch lane -> the late-lane memory-pressure leak. Dispose
+                // on EVERY exit path, including the stray-message early return below. WasmDispatchResponse
+                // is a plain C# DTO (no JSObjects), so it stays valid after msg is disposed.
+                using var _msgScope = msg;
                 var tcs = state.CurrentTcs;
                 if (tcs == null) return; // No in-flight dispatch; ignore late or stray message.
                 state.CurrentTcs = null;
@@ -1898,6 +1907,9 @@ private void EnsurePersistentHandlers(Worker worker)
 
             state.ErrHandler = new Action<Event>((err) =>
             {
+                // Same ownership rule as MsgHandler: the Event JSObject is handler-owned and must be
+                // disposed on every path (rare - only fires on a worker-level error - but still leaks if not).
+                using var _errScope = err;
                 var tcs = state.CurrentTcs;
                 if (tcs == null) return;
                 state.CurrentTcs = null;

SpawnDev.ILGPU/Wasm/WasmMemoryBuffer.cs

@@ -4,8 +4,11 @@
 //
 // File: WasmMemoryBuffer.cs
 //
-// Manages GPU memory buffers backed by SharedArrayBuffer regions.
-// Each buffer is a slice of a SharedArrayBuffer for zero-copy sharing across workers.
+// Manages GPU memory buffers, each backed by its OWN SharedArrayBuffer (persistent device storage).
+// Per dispatch the SAB is staged into/out of the shared WebAssembly linear memory on the MAIN thread
+// (copy-IN before, copy-OUT after); workers run against the linear memory, NOT against per-buffer SABs
+// (only the shared linear memory is PostMessage'd to workers). The SharedArrayBuffer backing enables
+// zero-copy host-side reads/writes and SAB-to-SAB (Wasm-to-Wasm) device copies.
 // ---------------------------------------------------------------------------------------
 
 using global::ILGPU;
@@ -17,7 +20,8 @@
 namespace SpawnDev.ILGPU.Wasm
 {
     /// <summary>
-    /// Wasm memory buffer backed by a SharedArrayBuffer for zero-copy sharing across workers.
+    /// Wasm memory buffer backed by its own SharedArrayBuffer. Staged into/out of the shared
+    /// WebAssembly linear memory per dispatch (workers run against the linear memory, not this SAB).
     /// </summary>
     public class WasmMemoryBuffer : MemoryBuffer, IBrowserMemoryBuffer
     {