1437470 - Per-compartment hard limits on memory usage

Status: NEW

(Core :: JavaScript: GC, enhancement, P3)

Description

[Paul Bone [:pbone] (PTO until 14/8/2025)]

Can we implement a hard limit on memory usage (by compartiment) so that users can limit the amount of memory used by a given tab or page and configure this limit? (and provide it in about:config for power-users)

One challenge might be accounting for the malloc memory used by JS objects.

Comment 1

[Jan de Mooij [:jandem]]

It will probably be easier to do this per Zone (a Zone also corresponds more or less with a tab). One challenge will be memory allocated on the DOM side, but APIs could be added for that.

Comment 2

[Paul Bone [:pbone] (PTO until 14/8/2025)]

yeah, I was just now wondering if SpiderMonkey has any influence in the scheduling of the cycle collector.  But yes, Zones are easier to account for.  I'm just really fuzzy how Compartments and Zones map onto concepts that the user deals with.

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Memory usage for a tab is not trivial to compute, though maybe memory used for JS is enough of a proxy for the most common cases a user cares about (out of control iframe reloading...), outside of things like videos.

What is the browser going to do if a tab reaches the limit?

Comment 4

[Paul Bone [:pbone] (PTO until 14/8/2025)]

(In reply to Andrew McCreight [:mccr8] from comment #3)
> What is the browser going to do if a tab reaches the limit?

If it's just a limit for memory created by JavaScript, I imagine it'll work like our other limits.  It will fail to allocate which (I think) results in a JS exception.

It'd fail to allocate after trying things like collecting the heap & compacting the heap.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

This would also map into ideas I'm investigating to allow parent documents to use feature-policy to limit iframes within them, and perhaps also to specify to the system what to do if an iframe (or document if it's top-level-header feature-policy) triggers the limits.  Possible actions would be freezing execution and events for the frame; reloading it; warning the user, much more severely throttling it; failing allocations (per above); notifying the higher-level document (are there origin-leakage issues there?), etc.

However, this is predicated on being able to know when such a limit is reached.

Which construct would map to an iframe?  Compartment?  More complex than that?

Comment 6

[Chris]

Please bump this up, perhaps solving the easier memory accounting parts first.

Yesterday, I was developing a tiny web page on Linux (PopOS) and accidentally created an endless loop in Javascript that ate memory (by growing an array). My entire OS became inoperable and had to be hard-rebooted. I was surprised this could happen due to Javascript (a sandboxed browser language), running in a web page (a sandboxed app) running in a Firefox browser that is supposed to protect users from the world wild web. One errant line of legal Javascript in HTML should not equate to a denial-of-service attack.

A sensible approach would be similar to the nice warning given when a script takes too much CPU, offering the user the choice to continue or stop the script when a tab exceeds some reasonable size: a fixed MB size, or say 10% of real RAM memory.

Ideally there should also be some hard limit calculated by Firefox according to the machine's available memory and Firefox's reasonable percentage of it. For example, maybe limit Firefox (all tabs combined) to 50% or maybe 75% of real memory, so that the O/S has a reasonable chance to remain operational so that a bad tab can be closed. Otherwise, Firefox could cause the O/S to lock up, resulting in data loss if there are tabs or other apps outside of Firefox that have unsaved changes.

Regarding the calculation of memory, I don't think it necessarily needs to be perfect. For example, if it's difficult to track DOM allocations, then measure it in bulk, or just ignore it for now. I think a memory limit for the Javascript engine would be a fine start. Then, add DOM and other usage areas later.

Thanks for your consideration!

Comment 7

[Chris]

See also bug# 1537871

Comment 8

[Andrew McCreight (out of office until 8/21) [:mccr8]]

An infinite loop like that should be caught by the slow script dialog. There could be some issue with it.

The big problem with any kind of resource limit is that what is "reasonable" depends on the user, the computer, and what task they are doing. If you are editing your giant midterm essay that is due in two hours, maybe you are okay with it consuming every last bit of resources on your machine, but not if you are just looking up the latest sports score. A while back, somebody reduced the timeout in Firefox for Flash plugins to kill the plugin if it hung for like 45 seconds to around 10 seconds, but lots of people complained, because some game they liked to play had a hang for that long, and they were okay with waiting it out. A workaround there is to start popping up dialogs, but maybe the user is more annoyed by the dialogs than they would be by a little bit of extra memory being used.

Comment 9

[Chris]

Good points, Andrew, but...

Regarding inconvenience, I think we're talking about different orders of magnitude. The inconvenience of warning popups doesn't really compare to the inconvenience and potential data loss of a locked-up O/S. I think limiting Firefox to use less-than-all memory is a reasonable limitation. Any limit that equated to "100% - reasonable O/S minimum" would be logical and acceptable to users. Any alternative is moot when your O/S crashes.

Regarding the "slow script" feature, that's interesting, but I assume its logic was designed to monitor only CPU usage. A memory leak doesn't necessarily affect CPU. And even it if does (e.g. my endless loop example), apparently the "slow script" feature doesn't/can't react soon enough to the CPU symptom before all the memory is already scooped up. So I think memory needs to be protected by a separate safeguard.

The "giant midterm essay" example isn't really the same problem, since you control the size of the essay. A warning popup might convince you to split the essay into two files for example. If you risk it and lose the whole essay when the editor crashes, well, that's your fault. Conversely, a run-away web page downloaded on the world wild web is a different situation.... You can't fix that, so it's currently an all or nothing gamble when using Firefox. And if "all" means crashing your O/S, then it's really the same as -- or worse than -- "nothing."

Even worse, what if Firefox's current memory "freedom" was weaponized? What if someone designs their web site to detect an unwelcome O/S, and then mysteriously crashes the machine. What if some Chrome fanatic detected users' browsers and crashed the O/S only when visited by Firefox? Hey, if I didn't discover this problem with my own HTML/JS code, I definitely would have suspected Firefox was buggy, not the web page.

Regarding your last example, what's "Flash?" ;-p lol