Large Emscripten-y pages can use almost all system memory, so we don't want to keep them around. (Bug 810164 is an example of somebody disabling the bfcache for certain types of pages that could be looked at.)
We don't keep bfcache'd documents alive too long, but sure. Can we easily know which page is keeping the arraybuffer alive? I guess the creator, but how to get from jseng to DOM in that case?
For this and other bugs, we're going to have to add some kind of JS engine tracking of compartments (zones?) with large array buffers, so I'm imagining for this bug we add a new JS API call that takes a compartment (which will be the window global, say) and returns a boolean that will be false if we shouldn't bfcache it.
> We don't keep bfcache'd documents alive too long, but sure. The scenario here is where the page basically takes almost all system memory, so if we don't ditch it as quickly as possible when we're not actively using it, we're going to crash.
Perhaps instead we should use njn's per tab memory reporter thing, and stop bfcaching things that use a lot of memory.
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #4) That's certainly an exciting proposition; far closer to what the abstract ideal would be. Do you think it'd be fast enough not to jank tab-close? We do some expensive stuff like iterate over all heap cells. One could imagine a conservative/faster summary mode...
You pretty much have to do the full memory reporting stuff, such as iterating over all cells and measuring what malloc'd stuff hangs off them. Otherwise you'll miss arrays with a bazillion slots, etc. As for speed, on my (admittedly fast) machine, we're talking roughly 10ms for gmail.com.
Whiteboard: [MemShrink][games] → [MemShrink:P2][games]
So I stumbled my way to nsDocument::CanSavePresentation and, coincidentally, all the Emscripten apps I tried (Citadel, Monster Madness, BananaBench) already return false, failing on the (manager && manager->HasUnloadListeners()) check. Within 10 or so seconds, the large ArrayBuffer is finalized. I see a window.addEventListener("unload", SDL.receiveEvent) so I guess that's why :) One could consider setting the unload hook to be an app hint. Also, IIRC, the "memory-pressure" notification will drop the bfcache. Is that right bz? If so, then we might not need any special work here for games; bug 936236 should handle the reload case.
So, sounds like "yes" :)
You need to log in before you can comment on or make changes to this bug.