(In reply to Gabriele Svelto [:gsvelto] from comment #7) > We do need to prioritize the main process then, possibly by tweaking the delay behavior in content processes to ensure that they never take down the browser if it can be helped. I had suggested a few different approaches for this (such as letting content processes have a shorter delay-before-crash compared to the main process) but I'll leave it to you to pick the best approach. That's probably the simplest option; and in the absence of other constraints, I suppose that makes it the best. On the one hand, I expect that it _will_ still increase the main process OOM rate above the baseline of "don't stall at all in content processes", and that we'll have to make a decision as to what ratio we find acceptable. On the other hand, I don't expect it to increase the OOM rate _much_ -- the increase may not even be measurable in Nightly.
Bug 1785162 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Gabriele Svelto [:gsvelto] from comment #7) > We do need to prioritize the main process then, possibly by tweaking the delay behavior in content processes to ensure that they never take down the browser if it can be helped. I had suggested a few different approaches for this (such as letting content processes have a shorter delay-before-crash compared to the main process) but I'll leave it to you to pick the best approach. That's probably the simplest option; and in the absence of other constraints, I suppose that makes it the best. (On the one hand, I expect that it _will_ still increase the main process OOM rate above the baseline of "don't stall at all in content processes", and that we'll have to make a decision as to what ratio we find acceptable. On the other hand, I don't expect it to increase the OOM rate _much_ -- the increase may not even be measurable in Nightly.)