Bugzilla

I realized only now that we have a DMD report from comment 18 on this bug and spent a few more tokens to look into it:

After symbolicating against the matching 148.0a1 build (`20260106100019`) and re-running `dmd.py`, the Jan 6 DMD snapshot of the youtube.com content process (PID 14240, ~18.8 GB resident) breaks down like this:

- The leak is concentrated in one realm: the YouTube embed iframe `https://www.youtube.com/embed/BHIb20_bOzo` on the mobalytics page. That single iframe's GC heap holds ~639 MB of `LexicalEnvironment` objects and ~409 MB of `Function` objects — on the order of ~10M live closures.
- On the C++ side, the live-block records under `Window_Binding::setInterval` and `Window_Binding::setTimeout` together account for ~5.0 GB of source-location strings (`CallbackTimeoutHandler` ctor → `JSCallingLocation::Get`) and ~500 MB of `Timeout` object allocations from `TimeoutManager::SetTimeout` ([dom/base/TimeoutManager.cpp:522](https://searchfox.org/firefox-main/rev/af3e8a085afcc67dbb95f252360f557b3a175aa1/dom/base/TimeoutManager.cpp#518-528)). The split is ~6M `setInterval` callsites vs ~3.7M `setTimeout` callsites (~1.6:1).

So the timer-pile-up reading from comment #43 holds, with the caveat that *both* setInterval and setTimeout were active in the runaway, not just one — so the precise mechanism may be a fan-out across multiple targets rather than a single retry chain.

As this is based on a snapshot four months old, if this still reproduces reliably for you, two artifacts may help, taken in separate sessions:

1. **A fresh DMD.zip**, captured the same way as comment #18 (set `DMD=1` in your Windows System Variables, reproduce the leak, then "Save DMD output" + "Measure and Save"). This will tell us whether the call-site distribution still looks the way it did in January, or whether something has shifted.
2. **A separate profile *without* `DMD=1` set** — just use the profiler's **Memory** preset on a clean Nightly with the userscript active, reproduce the leak, and share the link. The reason for asking for this separately is that DMD itself adds significant per-allocation bookkeeping (about 5.6 GB of `explicit/dmd/live-block-table` overhead in the Jan 6 snapshot, plus very high reporter traffic). For diagnosing the runaway timing and CC slice cost, a non-DMD profile is much more representative of what users actually experience. The earlier the profiling starts to capture the adding of the timers, the better.

Thank you for your patience!

I realized only now that we have a DMD report from comment 18 on this bug and spent a few more tokens to look into it:

After symbolicating against the matching 148.0a1 build (`20260106100019`) and re-running `dmd.py`, the Jan 6 DMD snapshot of the youtube.com content process (PID 14240, ~18.8 GB resident) breaks down like this:

- The leak is concentrated in one realm: the YouTube embed iframe `https://www.youtube.com/embed/BHIb20_bOzo` on the mobalytics page. That single iframe's GC heap holds ~639 MB of `LexicalEnvironment` objects and ~409 MB of `Function` objects — on the order of ~10M live closures.
- On the C++ side, the live-block records under `Window_Binding::setInterval` and `Window_Binding::setTimeout` together account for ~5.0 GB of source-location strings (`CallbackTimeoutHandler` ctor → `JSCallingLocation::Get`) and ~500 MB of `Timeout` object allocations from `TimeoutManager::SetTimeout` ([dom/base/TimeoutManager.cpp:522](https://searchfox.org/firefox-main/rev/af3e8a085afcc67dbb95f252360f557b3a175aa1/dom/base/TimeoutManager.cpp#518-528)). The split is ~6M `setInterval` callsites vs ~3.7M `setTimeout` callsites (~1.6:1).

So the timer-pile-up reading from comment #43 holds, with the caveat that *both* setInterval and setTimeout were active in the runaway, not just one — so the precise mechanism may be a fan-out across multiple targets rather than a single retry chain.

As this is based on a snapshot four months old, if this still reproduces reliably for you, two artifacts may help, taken in separate sessions:

1. **A fresh DMD.zip**, captured the same way as comment #18 (set `DMD=1` in your Windows System Variables, reproduce the leak, then "Save DMD output" + "Measure and Save"). This will tell us whether the call-site distribution still looks the way it did in January, or whether something has shifted.
2. **A separate profile *without* `DMD=1` set** — just use the profiler's ~~Memory~~ **WebCompat** preset on a clean Nightly with the userscript active, reproduce the leak, and share the link. The reason for asking for this separately is that DMD itself adds significant per-allocation bookkeeping (about 5.6 GB of `explicit/dmd/live-block-table` overhead in the Jan 6 snapshot, plus very high reporter traffic). For diagnosing the runaway timing and CC slice cost, a non-DMD profile is much more representative of what users actually experience. The earlier the profiling starts to capture the adding of the timers, the better.

Thank you for your patience!