Garbage collection timing
Slap yourself if
You assume memory will be freed shortly after objects become unreachable.
Why this exists
Garbage collection timing exists because freeing memory competes with keeping the UI responsive. Browsers intentionally decouple reachability from reclamation, trading determinism for throughput and latency guarantees.
Mental model
Garbage collection answers two different questions: what can be freed, and when it’s safe to pay the cost of freeing it. Developers usually understand the first and completely misjudge the second.
- Objects become eligible for collection when unreachable.
- The engine schedules GC based on heuristics, not eligibility.
- Memory may remain allocated across many frames or navigations.
- Collection work is split, delayed, or skipped to avoid jank.
- Interpreting delayed memory release as a leak.
- Forcing GC assumptions into performance debugging.
- Benchmarking without accounting for GC cycles.
- Treating heap size as a real-time correctness signal.
Garbage collection timing refers to when the engine actually reclaims memory after objects become unreachable, which is governed by heuristics and performance tradeoffs rather than deterministic rules.
- Expecting memory to drop immediately after cleanup
- Calling manual cleanup code to ‘force GC’
- Judging leaks from a single heap snapshot
- Assuming idle time guarantees collection
Deep dive
Premium deep dives include more internals, more scars.