Discuss current pattern of creating a new thread for serial execution guarantees using coroutines

[mcomella]

I'm creating this issue to discuss during triage.

In a few places in the code, the comments indicate we use singleThreadExecutors to serialize execution of the code:

• https://searchfox.org/mozilla-mobile/rev/0d8307b3d2c9fdbc13248ec29a1e4b1f6e6c67d8/android-components/components/service/firefox-accounts/src/main/java/mozilla/components/service/fxa/manager/FxaAccountManager.kt#129-132
• https://searchfox.org/mozilla-mobile/rev/0d8307b3d2c9fdbc13248ec29a1e4b1f6e6c67d8/android-components/components/support/migration/src/main/java/mozilla/components/support/migration/FennecMigrator.kt#264-265

In addition to some areas of the code that look like they use singleThreadExecutors to serialize execution but don't explicitly comment as such.

This seems like an unnecessary theoretical performance hit to me – we have existing thread pools that can be re-used, avoiding thread allocation time, memory considerations, and context switching time. I'm thinking of a mechanism similar to Apple's Grand Central Dispatch's serial DispatchQueues (or even Android Handler queues) where execution of tasks on the queue is guaranteed to be sequential and non-overlapping by FIFO ordering:

DispatchQueue.main.async {
    // Do something
}

In practice

In practice, we don't know what the impact of having so many threads is (currently, we have over 100 registered on start up). Ideally, we'd make a prototype and measure the difference in implementations. However, threading can have an inconsistent impact on app behavior so this may be hard to do.

Furthermore, there's an open question: what pattern should new code use? If we continue creating new threads for every sequential execution need, we may start to see performance impacts even if we're not seeing them now.

Questions

• What should the default implementation be when adding code that requires sequential execution? A single threaded executor or re-using existing Dispatchers with serial execution queues?
• Are there theoretical best guesses for performance to not use the built-in dispatchers? For example, if we want no fetch 8 favicon thumbnails on start up, we may not want to create 8 new threads on the IO dispatcher (which is the default behavior) Which existing use cases of new serial thread pools have a legitimate reason to do so?
• If we decide to change the default, should we bother changing code that already uses the old pattern of new executor?

Sequential FIFO APIs

The coroutines APIs that I'm aware of that might be relevant for sequential, non-overlapping FIFO ordering are:

• Mutex (based on the name, this may not guarantee ordering, however)
• Channel (it's a queue API but I'm not sure how ergonomic the API is for sequential, non-overlapping tasks)

[mcomella]

We could try spawning the same number of threads in a sample app and measure it compared to the default to see how it affects startup time, maybe?

[mcomella]

We might be able to do some rough measuring with the vmstat command, which has a measure of the "number of context switches per second" and "the time spent running kernel code". There are other measures that might be useful to us for other purposes, such as "time spent waiting on IO".

[mcomella]

Triage: This is a subset of https://github.com/mozilla-mobile/android-components/issues/9424 so we'll leave this issue in triage to remind us to check in with that issue to make sure it gets worked on.

[mcomella]

Triage: this isn't urgent for the FE perf team b/c we're focused on start up: low priority. However, csadilek has memory consumption analysis https://github.com/mozilla-mobile/fenix/issues/17590 on their radar, which relates to this, so it may get addressed by them.