936218 - Disable the bfcache for pages with very large ArrayBuffers

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Andrew McCreight [:mccr8]]

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.)

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 2

[Andrew McCreight [:mccr8]]

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.

Comment 3

[Andrew McCreight [:mccr8]]

> 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.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Perhaps instead we should use njn's per tab memory reporter thing, and stop bfcaching things that use a lot of memory.

Comment 5

[Luke Wagner [:luke]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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...

Comment 6

[Nicholas Nethercote [inactive]]

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.

Comment 7

[Luke Wagner [:luke]]

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.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

http://mxr.mozilla.org/mozilla-central/source/docshell/shistory/src/nsSHistory.cpp#194
f

Comment 9

[Luke Wagner [:luke]]

So, sounds like "yes" :)

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.