The 39 MB belongs to WebKit's process cache. WKWebView runs page content in a separate WebContent process, and WebKit holds that process warm after you navigate away so the next navigation is fast [15]. Three attempts to reclaim it are documented: releasing the last reference to the WKWebView left the process alive after 110 seconds, giving each tab its own WKProcessPool had no effect, and navigating to about:blank before releasing the view measured 59 MB with the process still running [14]. 110 seconds is a while to keep watching something you have already released. That third result is why the COLD path now keeps the view and navigates it away instead [14]. There is no supported opt-out, and the private SPI `_WKProcessPoolConfiguration.usesWebProcessCache` would probably make teardown deterministic at the price of leaving supported API [15][16].
The arithmetic on the bad input: 32 KB against a measured 39 MB is an error of roughly 1,250x in the parameter every downstream claim rested on [5][6][1]. The headline ratio moved by far less, from 7.9-11.5x predicted to 1.4-2.6x measured, an overstatement of about 4.4x to 5.6x [3][4][2]. My read is that the floor only prices demoted tabs, while the LIVE ones in the mix still cost what a loaded page costs [8], so a wrong floor degrades the ratio without collapsing it.
WARM is the more instructive break, because the mechanism it depended on does not exist outside the engine. Detaching the view, suspending all media playback and clearing every timer and interval recovered 17%, against a design target under 2 MB [9]. The specification assumed a full compacting GC followed by `madvise`, and compaction is the step that actually returns pages to the OS; a host application cannot compact WebKit's heap and there is no API for it [10]. That parameter had been swept from 0.02 to 0.50 in simulation and reality returned 0.83, 1.66x worse than the most pessimistic value tested [11][3]. A sweep protects you only inside the range where your assumed mechanism holds.
The dead first experiment is worth reading closely, because it reads like a finding. Mean footprints came in at 197.8 MB unmanaged, 182.3 MB for discard-LRU and 181.0 MB for Kestrel, with zero demotions on every row [18]; Kestrel's margin over discard-LRU was 0.7% [5]. The budget was 400 MB and the unmanaged peak 320 MB, 25% of headroom, so no policy was ever asked to do anything [19][6].
For 1.4-2.6x to transfer you would need the same system WebKit, the process cache in play, and per-tab costs that stay near the measured floor. The naive extrapolation of that floor gives 39 x 80 = 3,120 MB at 80 tabs, the 3.1 GB the author quotes and then says he does not believe [17][4]. The cache is bounded and evicts under memory pressure, so the real floor at scale is probably lower, and nobody has measured where [17]. Every figure here is one machine: M1 Max, macOS 15.5, Swift 6.1.2 [7].
