Disable the bfcache for pages with very large ArrayBuffers

NEW
Unassigned

Status

()

Core
DOM
5 years ago
4 years ago

People

(Reporter: mccr8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

5 years ago
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

5 years ago
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?
(Reporter)

Comment 2

5 years ago
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.
(Reporter)

Comment 3

5 years ago
> 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.

Comment 5

5 years ago
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) 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...

Updated

5 years ago
Whiteboard: [MemShrink] → [MemShrink][games]
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.
(Reporter)

Updated

5 years ago
Depends on: 936292
Whiteboard: [MemShrink][games] → [MemShrink:P2][games]

Comment 7

4 years ago
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.
Flags: needinfo?(bzbarsky)

Comment 9

4 years ago
So, sounds like "yes" :)
Flags: needinfo?(bzbarsky)

Updated

4 years ago
Whiteboard: [MemShrink:P2][games] → [MemShrink:P2]

Updated

4 years ago
No longer blocks: 865959
You need to log in before you can comment on or make changes to this bug.