To reproduce: 1) recompile dom/workers/WorkerPrivate.cpp with -DWORKER_LOGGING 2) launch firefox, open about:blank and minimize the window 3) observe the periodic activity, e.g: Worker 0x10dbaec00 collected idle garbage Worker 0x10dbaec00 canceled GC timer because idle Worker 0x10dbaec00 scheduled idle GC timer
This seems like workers, not jseng....
What's the bug here? Every time a worker is used we schedule followup GCs. That seems normal to me.
Right. The question is then what are those workers doing during idle. On my machine I measured up to 20 wakeups per minute, due to workers, during a ten minutes idle run.
Ah, ok. That should be easy enough to pin down. Is this on desktop firefox or b2g?
It's on desktop firefox.
Ok, great! The simplest way to do this is probably modify the printfs that are triggered with the -DWORKER_LOGGING switch. Just make them additionally dump the mScriptURL member and it should be easy to tell which worker is waking up all the time.
The culprits are ///modules/sessionstore/SessionWorker.js and //gre/modules/osfile/osfile_async_worker.js.
Normally, neither thread has any activity unless there is something on the main thread requesting that something be done. If more information is needed, we can activate OS.File logging, by setting preference "toolkit.osfile.log" to true.
I'll move this over to the session storage component.
The common point between all these workers is OS.File, so moving again. I have Nightly currently running on idle, and OS.File doesn't seem to receive any messages. Since there is no code in OS.File (or in any of these threads) that causes any activity without messages, I'm tempted to think that the problem is either in js-ctypes or in workers, though.
I can reproduce here. OS.File isn't receiving any message but we get 2045159776: THRD(1004407c0) ProcessNextEvent [0 0] 2045159776: THRD(1004407c0) running  2045159776: [this=113968170] time between PostTimerEvent() and Fire(): 0.200333ms 2045159776: [this=1143ed5e0] expected delay time 60000ms 2045159776: [this=1143ed5e0] actual delay time 60001.915000ms 2045159776: [this=1143ed5e0] (mType is 1) ------- 2045159776: [this=1143ed5e0] delta 1ms 2045159776: [this=1143ed5e0] Took 0.233058ms to fire timer callback etc.
The workers are indeed not doing any activity. What seems to be happening here is the following: 1) an idle GC timer is fired which causes a GarbageCollectRunnable to be dispatched (http://hg.mozilla.org/mozilla-central/file/7a1445739c07/dom/workers/WorkerPrivate.cpp#l1407) and enqueued in the ControlQueue (http://hg.mozilla.org/mozilla-central/file/7a1445739c07/dom/workers/WorkerPrivate.cpp#l2239) 2) the GarbageCollectRunnable is processed (http://hg.mozilla.org/mozilla-central/file/7a1445739c07/dom/workers/WorkerPrivate.cpp#l3970) in the worker’s event loop 3) an idle GC timer is set with a delay of 5 seconds (http://hg.mozilla.org/mozilla-central/file/7a1445739c07/dom/workers/WorkerPrivate.cpp#l4028); 4) goto 1. Is there a reason why garbage collection should be performed when a worker isn’t doing any activity?
Created attachment 8350451 [details] [diff] [review] Patch, v1 Hm, looks like I missed this somehow!