Closed
Bug 951671
Opened 11 years ago
Closed 11 years ago
Periodic Worker activity during idle (osfile_async_worker.js, SessionWorker.js, PageThumbsWorker.js)
Categories
(Core :: DOM: Workers, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: rvitillo, Assigned: bent.mozilla)
References
Details
Attachments
(1 file)
3.61 KB,
patch
|
khuey
:
review+
|
Details | Diff | Splinter Review |
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
![]() |
||
Comment 1•11 years ago
|
||
This seems like workers, not jseng....
Component: JavaScript Engine → DOM: Workers
Assignee | ||
Comment 2•11 years ago
|
||
What's the bug here? Every time a worker is used we schedule followup GCs. That seems normal to me.
Reporter | ||
Comment 3•11 years ago
|
||
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.
Assignee | ||
Comment 4•11 years ago
|
||
Ah, ok. That should be easy enough to pin down. Is this on desktop firefox or b2g?
Summary: GC causes activity spikes during idle → Periodic Worker activity during idle
Reporter | ||
Comment 5•11 years ago
|
||
It's on desktop firefox.
Assignee | ||
Comment 6•11 years ago
|
||
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.
Reporter | ||
Comment 7•11 years ago
|
||
The culprits are ///modules/sessionstore/SessionWorker.js and //gre/modules/osfile/osfile_async_worker.js.
Comment 8•11 years ago
|
||
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.
Updated•11 years ago
|
Summary: Periodic Worker activity during idle → Periodic Worker activity during idle (osfile_async_worker.js, SessionWorker.js)
Assignee | ||
Comment 9•11 years ago
|
||
I'll move this over to the session storage component.
Component: DOM: Workers → Session Restore
Product: Core → Firefox
Reporter | ||
Updated•11 years ago
|
Summary: Periodic Worker activity during idle (osfile_async_worker.js, SessionWorker.js) → Periodic Worker activity during idle (osfile_async_worker.js, SessionWorker.js, PageThumbsWorker.js)
Updated•11 years ago
|
Component: Session Restore → OS.File
Product: Firefox → Toolkit
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[100462660]: THRD(1004407c0) ProcessNextEvent [0 0]
2045159776[100462660]: THRD(1004407c0) running [113968170]
2045159776[100462660]: [this=113968170] time between PostTimerEvent() and Fire(): 0.200333ms
2045159776[100462660]: [this=1143ed5e0] expected delay time 60000ms
2045159776[100462660]: [this=1143ed5e0] actual delay time 60001.915000ms
2045159776[100462660]: [this=1143ed5e0] (mType is 1) -------
2045159776[100462660]: [this=1143ed5e0] delta 1ms
2045159776[100462660]: [this=1143ed5e0] Took 0.233058ms to fire timer callback
etc.
Reporter | ||
Comment 12•11 years ago
|
||
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?
Reporter | ||
Updated•11 years ago
|
Component: OS.File → DOM
Product: Toolkit → Core
Reporter | ||
Updated•11 years ago
|
Component: DOM → DOM: Workers
Assignee | ||
Comment 13•11 years ago
|
||
Hm, looks like I missed this somehow!
Attachment #8350451 -
Flags: review?(khuey) → review+
Assignee | ||
Comment 14•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in
before you can comment on or make changes to this bug.
Description
•