558555 - [OOPP] plugin process should run with a lower priority than the browser process

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Bill Gianopoulos [:WG9s]]

Currently, the sub-process created for plug-in execution runs at the same priority as the main browser process.  This means that if the plug-in causes a loop, you cannot gain control over it via the browser process to close the offending tab (at least on a 1 cpu system anyway).  It would be better if the plugins ran at a lower priority than the browser to prevent this.

Comment 1

[Jan]

On WinXP (up-to-date home edition), flash manages to freeze not only firefox, but the whole system, so you cannot even run task manager to kill the mozilla-runtime process. (It starts working after some time, usually around 20-30 sec.)

Manually lowering the priority before it happens solves the problem.

see also bug 551421, bug 556220, bug 541942

Comment 2

[u88484]

See also bug 558339 which is also about flash sucking up cycles and not allowing firefox and more importantly the OS to respond.

Comment 3

[Benjamin Smedberg]

Data from bug 558629 says that lowering the plugin process priority makes at least that class of interaction worse, not better.

Jan/Bill: does flash eat CPU cycles the same way if you turn OOPP off completely?

Comment 4

[Bill Gianopoulos [:WG9s]]

(In reply to comment #3)
> Data from bug 558629 says that lowering the plugin process priority makes at
> least that class of interaction worse, not better.
> 
> Jan/Bill: does flash eat CPU cycles the same way if you turn OOPP off
> completely?

Under LINUX, I do not see a significant amount of difference between the percentage of CPU used by firefox-bin for the non-OOPP case and the combination of firefox-bin and plugins-container for the OOPP case.

Further, trying turning OOPP back on today, I really do not see the same issue I did when I reported this issue, which was that flash performance was much worse with OOPP enabled and it did not seem possible to stop a flash plugin by trying to close the tab.  So whatever that issue was has evidently been fixed by some check-in that occurred in the interim.

Comment 5

[[Baboo]]

Couldn't this be made another technique for lowering the impact of background tabs in line of the other proposals blocking bug 595574?

Comment 6

[Benjamin Smedberg]

No, this bug has nothing to do with content processes or their priority, only plugin processes.

Comment 7

[[Baboo]]

I understand that, still I see this as another way for lowering the overall load (regardless of which process) caused by background tabs, in this case the ones with plugins running OOP.

Comment 8

[[not reading bugmail]]

Its not the background tabs that are the problem with flash in them, its the foreground tabs with flash.. 

Ben, would working on this slow down flash from living in a vacuum and bring balance to the force?

Comment 9

[[Baboo]]

Why should background tabs with flash be any less of a problem? AFAIK, plugins don't care if they are in a background or foreground tab, they always run on 100%

Comment 10

[Jim Mathies [:jimm]]

(In reply to comment #9)
> Why should background tabs with flash be any less of a problem? AFAIK, plugins
> don't care if they are in a background or foreground tab, they always run on
> 100%

They don't paint to a surface. The vast majority of work they do tends to relate to painting.