865354 - Consider consolidating system workers

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Alon Zakai (:azakai)]

In a recent dev.platform discussion it came up that the overhead for individual workers is noticeable in about:memory, due to each worker havings its own runtime, GC arena, etc.

A possible short-term improvement could be to consolidate workers - what are now separate workers could be shared in one worker, with the message handling code routing to the right one.

This can't work if the workers are long-running and need to run in parallel, of course (and even if short-running, it would decrease use of multiple cores, but on single-core phones that might not matter much). Not sure what the situation is with the relevant workers, opening this bug for discussion/investigation.

Comment 1

[Alon Zakai (:azakai)]

Relevant discussion: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/XMkcvEAeA60

Comment 2

[Alon Zakai (:azakai)]

From jlebar's about:memory as linked in that discussion, the relevant workers are

ril_worker.js
net_worker.js
and two wifi_worker.js

Comment 3

[Alon Zakai (:azakai)]

Not sure who mainly works on these files, so cc'ing some people that I see in the hg logs for them. Any thoughts on the feasibility of this bug would be welcome, and sorry if I am cc'ing the wrong people.

Comment 4

[Justin Lebar (not reading bugmail)]

It was pointed out to me that we don't (usually?  ever?) use the Gecko RIL in production.  If that's true, we only would need to merge the other three workers.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

(In reply to Justin Lebar [:jlebar] from comment #4)
> It was pointed out to me that we don't (usually?  ever?) use the Gecko RIL
> in production.  If that's true, we only would need to merge the other three
> workers.

Depends on which chipset we're running. For now, production chipsets are all the same, so I'd call it "usually" but not "ever".

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

The whole reason that these things are workers to begin with is that they block on reading/writing to special file descriptors. We'd need to change from a single-fd to a multiple-fd system and then figure out where to deliver the data. We'd also have fun dealing with the case of trying to write to an fd while there's an incoming call, etc. Then we'd have to merge the main thread scripts to route the incoming messages as well...

I'd say this is doable but not trivial.

Comment 7

[Justin Lebar (not reading bugmail)]

> The whole reason that these things are workers to begin with is that they block on reading/writing 
> to special file descriptors.

That was the key piece of data I needed.  Sounds like we shouldn't do this.