1576135 - Lots and lots of remaining MediaPlayback threads when running raptor-youtube-playback tests

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1] (away from Feb 12th - Feb 22nd)]

When i check the profile from the following job I can see that MediaPlayback threads are accumulating, and never seem to be destroyed. Means that we have more than 60 or so threads present for the single WebContent process. Note that the job is from try and all its artifacts will appear sooner than later. The bug to get those jobs running regularly on central is bug 1553131.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cd4bf4acbe0003163564407c114b9ccd900858a&selectedJob=262281894

Please note that downloading this file can take a while given it's size is simply huge!

Jean-Yves gaves an answer to the same question on that other bug:

(In reply to Jean-Yves Avenard [:jya] from bug 1553131 comment #9)

(In reply to Paul Adenot (:padenot) from comment #8)

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #6)

Paul, is that expected? Or should we be more aggressive in destroying no-longer needed threads?

jya, do we do anything to shut down the thread pool backing the task queue?

The media code use a SharedThreadPool, it gets automatically shutdown (and all threads it contains) as soon as it's no longer in use and now one is referencing it.

The SharedThreadPool will create as many threads as needed to run all tasks given to it, so long that the thread limit isn't reached (which is currently 4 by default).

There are a few SharedThreadPool in use (playback, msg, mdsm) etc. but it can't go to 60.

There is an issue however with how a nsThreadPool destroy a thread. It queue a task to the main thread. If the SharedThreadPool is used on the main thread and some code is blocking the main thread, the task to free the thread will never run and so the number of threads could look like it's creeping. I have opened that bug a few weeks ago (bug 1573072).

However, I'm not sure this is what is happening here.

In short, unless you're in the situation I described just before, there's no way the media SharedThreadPool could have 60 threads in it.
https://searchfox.org/mozilla-central/source/xpcom/threads/nsThreadPool.cpp#87

I will forward the needinfo request for Alwu from Nils.

To reproduce it locally with automation you could try to run the following command:

./mach raptor-test --test=raptor-youtube-playback

Otherwise running all the tests directly on the page by clicking Run All might also work:

https://yttest.prod.mozaws.net/2019/main.html?test_type=playbackperf-test

Comment 1

[Alastor Wu [:alwu]]

From the profiler result, I saw that we have at most 4 media playback thread at the same time, which match our expectation, and all those threads are executing

So this bug seems to me like a false alarm, because all those threads are executing media related tasks during playing video for yt test so they're not idle.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1] (away from Feb 12th - Feb 22nd)]

Oh I see. I forgot that the profiler records the threads over all the time it is running. And as it has mentioned by Alastor, and can also be seen by the cascading list of MediaPlayback threads, those are indeed getting destroyed and created for each video.

I agree that this bug is not valid.