871742 - Disable the watchdog thread on B2G for everything but browser processes

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Bobby Holley (:bholley)]

Doug and I were just discussing this IRL.

Because the watchdog thread is per-process, our multiprocess makes watchdogs significantly more expensive, because we have N of them waking up once per second.

As it turns out, we totally ignore the watchdog thread for chrome JS on B2G:

http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#176

This pref, however, doesn't disable the (expensive) Watchdog + OperationCallback machinery that delivers the DOMOperationCallback - it just ignores the callback when it arrives.

Given that the parent process in b2g should never be running content JS, it seems like we should just disable the watchdog thread entirely in that case.

Moreover, doug pointed out that we probably shouldn't be doing a slow script dialog for app processes either - if they become unresponsive, we should just kill them.

This doesn't change the situation for the browser app, where we probably really do want the slow script dialog. But it puts us in a much better place.

How can we detect in XPConnect initialization which of these many situations we're dealing with?

Comment 1

[Justin Lebar (not reading bugmail)]

> Given that the parent process in b2g should never be running content JS, it seems like we should 
> just disable the watchdog thread entirely in that case.

This makes sense to me.

> Moreover, doug pointed out that we probably shouldn't be doing a slow script dialog for app 
> processes either - if they become unresponsive, we should just kill them.

We have to be careful how we define "unresponsive".  With our current definition, we get bug 870541, which is problematic.

OTOH suppose an app goes into an infinite loop and we don't have any "unresponsiveness" handling of it.  The user will notice that the app is looping and hit the home button.  But the app is still running!  Whenever the phone's CPU is on, that app will sit in the bg and suck up battery.

Slow-script killing of one form or another helps with this problem, but of course it doesn't solve the problem; the site can just use setTimeout().  Maybe we throttle setTimeout while it's in the bg, but that still doesn't solve the problem.  We probably should just be freezing these apps; give them zero cpu.

IOW, I think I'd support not having a watchdog for apps, because we really need a better solution to actually fix the problem.

> How can we detect in XPConnect initialization which of these many situations we're dealing with?

We probably just want to send the parameters down with the ContentChild initializer before ContentChild::InitXPCOM() is called by ContentProcess.cpp.  The SendGetProcessAttributes call in ContentChild::Init() may be early enough.

Comment 2

[Justin Lebar (not reading bugmail)]

"the browser app" is an app that runs in the main process -- I think you want us to disable the watchdog for everything except browser tabs.

Comment 3

[Bobby Holley (:bholley)]

(In reply to Justin Lebar [:jlebar] from comment #2)
> "the browser app" is an app that runs in the main process -- I think you
> want us to disable the watchdog for everything except browser tabs.

Oh, then in that case we can't disable the watchdog in the parent process then.

Comment 4

[Bobby Holley (:bholley)]

(In reply to Bobby Holley (:bholley) from comment #3)
> (In reply to Justin Lebar [:jlebar] from comment #2)
> > "the browser app" is an app that runs in the main process -- I think you
> > want us to disable the watchdog for everything except browser tabs.
> 
> Oh, then in that case we can't disable the watchdog in the parent process
> then.

Nevermind - I was confused.

Comment 5

[Bobby Holley (:bholley)]

(In reply to Justin Lebar [:jlebar] from comment #1)
> IOW, I think I'd support not having a watchdog for apps, because we really
> need a better solution to actually fix the problem.

Ok. But that better solution probably needs to come before we disable the watchdog, right?

Comment 6

[Justin Lebar (not reading bugmail)]

> Ok. But that better solution probably needs to come before we disable the watchdog, right?

It's not clear to me that what we have now is better than no watchdog in apps.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Justin Lebar [:jlebar] from comment #1)
> We probably should just be freezing these apps; give them zero cpu.

I filed bug 872177

Comment 8

[Bobby Holley (:bholley)]

I ended up disabling the watchdog thread for b2g in bug 870043 part 6.