Heap-aware, two-sided budgeting for the in-memory cache tiers (L0, L1,
S-cache).
The three JS-heap cache tiers used to be pinned to fixed config sizes
(L0 200 MB + L1 100 MB + S-cache 128 MB = 428 MB). That is simultaneously:
too SMALL on a large desktop heap — a fits-in-RAM timelapse's decoded
working set (~450 MB for the neuromast scene) exceeds the 128 MB S-cache,
so looped playback evicts and re-decodes every lap; and
too LARGE on a small mobile heap (jsHeapSizeLimit ~500 MB–1 GB), where
428 MB of hard-LRU caches is an OOM hazard before the render working set.
computeCacheBudgets derives per-tier budgets from the device heap so the
caches scale UP on big heaps (hold the whole timelapse → decode-free revisit)
and DOWN on small heaps (stay within a heap target → no OOM). It is the first
live consumer of config.dataLoading.memory.targetHeapUsage, and the first
stage of a future shared-pool coordinator.
Budgets are CEILINGS for demand-filled byte-LRUs, not reservations: a
generous S-cache ceiling costs nothing until a large dataset actually fills
it. Where the heap size is unknown (performance.memory is Chrome-only), the
fixed config sizes are returned verbatim — preserving today's behaviour on
Firefox/Safari and in the node/jsdom test environment.
Heap-aware, two-sided budgeting for the in-memory cache tiers (L0, L1, S-cache).
The three JS-heap cache tiers used to be pinned to fixed config sizes (L0 200 MB + L1 100 MB + S-cache 128 MB = 428 MB). That is simultaneously:
jsHeapSizeLimit~500 MB–1 GB), where 428 MB of hard-LRU caches is an OOM hazard before the render working set.computeCacheBudgetsderives per-tier budgets from the device heap so the caches scale UP on big heaps (hold the whole timelapse → decode-free revisit) and DOWN on small heaps (stay within a heap target → no OOM). It is the first live consumer ofconfig.dataLoading.memory.targetHeapUsage, and the first stage of a future shared-pool coordinator.Budgets are CEILINGS for demand-filled byte-LRUs, not reservations: a generous S-cache ceiling costs nothing until a large dataset actually fills it. Where the heap size is unknown (
performance.memoryis Chrome-only), the fixed config sizes are returned verbatim — preserving today's behaviour on Firefox/Safari and in the node/jsdom test environment.