Stop the RemoteDecoderChild from using a dedicated thread
Categories
(Core :: Audio/Video: Playback, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
Attachments
(3 files)
We can instead use a TaskQueue running on top of a media threadpool now that those are usable with IPC's MessageChannel
Assignee | ||
Comment 1•4 years ago
|
||
The base IProtocol class already provides this.
Assignee | ||
Comment 2•4 years ago
|
||
This allows to simplify the lifetime management off the RemoteDecoderModule's mManagerThread member.
Depends on D82501
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D82502
Assignee | ||
Comment 4•4 years ago
|
||
There are some reftests that launch dozens of video elements at once, on Windows the GpuDecoderModule dispatches a sync runnable to the RemoteDecoderManagerChild thread ; if we have more than 4 (the default for the "PLAYBACK" threadpool) then we won't spawn a new thread and all decoders ends up being blocked waiting for the task on the RemoteDecoderManagerChild to finally run.
Instead of relying on a sync dispatch to initialise IPDL, we should probably move that into the main GpuRemoteVideoDecoderChild::Init method so that it can be made to be fully async.
We would need to have a fallback mechanism to the remaining decoder if Init failed however, right now we only have a fallback to try other PDM if creation of the decoder failed rather than its initialisation failing.
Updated•4 years ago
|
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f779a3875a8 P1. Remove RemodeDecoderManagerChild::CanSend method. r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/35faa46f46f1 P2. Always initialise the RemoteDecoderChild manager thread. r=mjf https://hg.mozilla.org/integration/autoland/rev/de5e55b59a31 P3. Have RemoteDecoderManagerChild use a TaskQueue over a media threadpool. r=mjf
Comment 6•4 years ago
|
||
Backed out 5 changesets (bug 1650996, bug 1649974) for hazard failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/d8abefec5bba959f42bac66237b9eabe2d04dfaa
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308963824&repo=autoland&lineNumber=73953
...
[task 2020-07-08T12:51:30.770Z] Running explain to generate ('hazards.txt', 'unnecessary.txt', 'refs.txt')
[task 2020-07-08T12:51:30.770Z] LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/builds/worker/workspace/obj-haz-shell/dist/bin" PATH="/builds/worker/fetches/sixgill/usr/bin:${PATH}" XDB='/builds/worker/fetches/sixgill/usr/bin/xdb.so' SOURCE='/builds/worker/checkouts/gecko' ANALYZED_OBJDIR='/builds/worker/workspace/obj-analyzed' python2.7 /builds/worker/checkouts/gecko/js/src/devtools/rootAnalysis/explain.py rootingHazards.txt gcFunctions.txt hazards.txt unnecessary.txt refs.txt
[task 2020-07-08T12:51:33.400Z] Wrote explained_hazards.tmp
[task 2020-07-08T12:51:33.400Z] Wrote unnecessary.tmp
[task 2020-07-08T12:51:33.400Z] Wrote refs.tmp
[task 2020-07-08T12:51:33.400Z] Found 2 hazards 200 unsafe references 0 missing
[task 2020-07-08T12:51:33.401Z] Running heapwrites to generate heapWriteHazards.txt
[task 2020-07-08T12:51:33.401Z] LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/builds/worker/workspace/obj-haz-shell/dist/bin" PATH="/builds/worker/fetches/sixgill/usr/bin:${PATH}" XDB='/builds/worker/fetches/sixgill/usr/bin/xdb.so' SOURCE='/builds/worker/checkouts/gecko' ANALYZED_OBJDIR='/builds/worker/workspace/obj-analyzed' /builds/worker/workspace/obj-haz-shell/dist/bin/js /builds/worker/checkouts/gecko/js/src/devtools/rootAnalysis/analyzeHeapWrites.js > heapWriteHazards.txt
[task 2020-07-08T12:52:01.488Z] + check_hazards /builds/worker/workspace/analysis
[task 2020-07-08T12:52:01.489Z] + set +e
[task 2020-07-08T12:52:01.489Z] ++ grep -c 'Function.*has unrooted.*live across GC call' /builds/worker/workspace/analysis/rootingHazards.txt
[task 2020-07-08T12:52:01.490Z] + NUM_HAZARDS=2
[task 2020-07-08T12:52:01.490Z] ++ grep -c '^Function.*takes unsafe address of unrooted' /builds/worker/workspace/analysis/refs.txt
[task 2020-07-08T12:52:01.492Z] + NUM_UNSAFE=200
[task 2020-07-08T12:52:01.492Z] ++ grep -c '^Function.* has unnecessary root' /builds/worker/workspace/analysis/unnecessary.txt
[task 2020-07-08T12:52:01.494Z] + NUM_UNNECESSARY=1314
[task 2020-07-08T12:52:01.494Z] ++ grep -c '^Dropped CFG' /builds/worker/workspace/analysis/build_xgill.log
[task 2020-07-08T12:52:01.618Z] + NUM_DROPPED=0
[task 2020-07-08T12:52:01.619Z] ++ perl -lne 'print $1 if m!found (\d+)/\d+ allowed errors!' /builds/worker/workspace/analysis/heapWriteHazards.txt
[task 2020-07-08T12:52:01.621Z] + NUM_WRITE_HAZARDS=0
[task 2020-07-08T12:52:01.621Z] ++ grep -c '^Function.*expected hazard.*but none were found' /builds/worker/workspace/analysis/rootingHazards.txt
[task 2020-07-08T12:52:01.622Z] + NUM_MISSING=0
[task 2020-07-08T12:52:01.622Z] + set +x
[task 2020-07-08T12:52:01.622Z] TinderboxPrint: rooting hazards<br/>2
[task 2020-07-08T12:52:01.622Z] TinderboxPrint: (unsafe references to unrooted GC pointers)<br/>200
[task 2020-07-08T12:52:01.622Z] TinderboxPrint: (unnecessary roots)<br/>1314
[task 2020-07-08T12:52:01.622Z] TinderboxPrint: missing expected hazards<br/>0
[task 2020-07-08T12:52:01.622Z] TinderboxPrint: heap write hazards<br/>0
[task 2020-07-08T12:52:01.624Z] TEST-UNEXPECTED-FAIL | hazards | unrooted 'scopedArr' of type 'mozilla::dom::TypedArray<unsigned char, js::UnwrapUint8ClampedArray, JS_GetUint8ClampedArrayData, js::GetUint8ClampedArrayLengthAndData, JS_NewUint8ClampedArray>' live across GC call at dom/canvas/WebGLTextureUpload.cpp:947
[task 2020-07-08T12:52:01.624Z] TEST-UNEXPECTED-FAIL | hazards | unrooted 'obj' of type 'JSObject*' live across GC call at js/xpconnect/src/XPCJSRuntime.cpp:3253
[task 2020-07-08T12:52:01.624Z] TEST-UNEXPECTED-FAIL | hazards | 2 rooting hazards detected
[task 2020-07-08T12:52:01.624Z] TinderboxPrint: documentation<br/><a href='https://wiki.mozilla.org/Javascript:Hazard_Builds#Diagnosing_a_rooting_hazards_failure'>static rooting hazard analysis failures</a>, visit "Inspect Task" link for hazard details
[task 2020-07-08T12:52:01.624Z] + onexit
[task 2020-07-08T12:52:01.624Z] + grab_artifacts /builds/worker/workspace/analysis /builds/worker/artifacts
[task 2020-07-08T12:52:01.624Z] + local analysis_dir
[task 2020-07-08T12:52:01.624Z] + analysis_dir=/builds/worker/workspace/analysis
...
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/236757acc073 P1. Remove RemodeDecoderManagerChild::CanSend method. r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/374598f9c37a P2. Always initialise the RemoteDecoderChild manager thread. r=mjf https://hg.mozilla.org/integration/autoland/rev/8f8174ba409d P3. Have RemoteDecoderManagerChild use a TaskQueue over a media threadpool. r=mjf
Comment 8•4 years ago
|
||
Backed out for perma failures.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1649974#c14
Backout by rmaries@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b8fad3d28fcd Backed out 5 changesets (bug 1650996, bug 1649974) for perma failures on Android 7.0. CLOSED TREE
Assignee | ||
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/51ceb0b7150c P1. Remove RemodeDecoderManagerChild::CanSend method. r=mattwoodrow https://hg.mozilla.org/integration/autoland/rev/399f05bfe205 P2. Always initialise the RemoteDecoderChild manager thread. r=mjf https://hg.mozilla.org/integration/autoland/rev/f3ab1da2cea8 P3. Have RemoteDecoderManagerChild use a TaskQueue over a media threadpool. r=mjf
Comment 11•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/51ceb0b7150c
https://hg.mozilla.org/mozilla-central/rev/399f05bfe205
https://hg.mozilla.org/mozilla-central/rev/f3ab1da2cea8
Comment 12•4 years ago
|
||
Can we back this out of beta to address the regressions?
Assignee | ||
Comment 13•4 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #12)
Can we back this out of beta to address the regressions?
The fix is safe. Wouldn't that be a better solution?
Comment 14•4 years ago
|
||
For 81 sure. For 80 I'm not convinced, and it's been sitting for 2 weeks already.
Assignee | ||
Comment 15•4 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #14)
For 81 sure. For 80 I'm not convinced, and it's been sitting for 2 weeks already.
And there's 26 days to go before release.
There's much more risk to backout this change (as it comes in a long series of thread changes published in the days prior and following) than uplifting the fix which is just using a different thread in webaudio to prevent deadlock.
Description
•