Bugzilla

I think what's happening here is that in xpcshell tests we create many `GeckoRuntime`s so that we can run multiple tests in parallel. Each of these runtimes attempts to launch their own GPU process but android only allows one instance of each service, in this case `org.mozilla.gecko.process.GeckoChildProcessServices$gpu`. So after the first runtime successfully launches the GPU process, each subsequent runtime attempting to do so will instead notify the existing instance we attempted to start it. The existing instance will see that it belongs to a different runtime, and log this warning, and we will repeatedly retry launching it.

This logging existed before bug 1741156, back when content processes were the only type of child process. While we only declare one `gpu` process service (and one `socket`, one `utility`, etc), we declare many content process ones, eg `tab1`, `tab2`, etc. If a GeckoRuntime attempts to launch a content process and picks a service already in use then we log this warning and retry with a random `tabN` until we find one which succeeds. However, with the GPU process (and socket process, utility process, etc) this will never succeed as we've only declared one service for the process type.

I'm unsure what the consequences of this are. Perhaps we can simply remove the logging. Or perhaps we could run in to issues with failing to launch child processes. We only support multiple GeckoRuntimes during tests so it's not an issue in the wild, but perhaps it might causes issues during tests. Maybe we need to declare multiple services for each type of child process and use the same logic as for content processes to select a random service name during launch. (or perhaps even a generic `childN` services could be used for both content and non-content child processes.) Kayacan, perhaps you or somebody else on the geckoview team might be better placed to answer that?

I think what's happening here is that in xpcshell tests we create many `GeckoRuntime`s so that we can run multiple tests in parallel. Each of these runtimes attempts to launch their own GPU process but android only allows one instance of each service, in this case `org.mozilla.gecko.process.GeckoChildProcessServices$gpu`. So after the first runtime successfully launches the GPU process, each subsequent runtime attempting to do so will instead notify the existing instance we attempted to start it. The existing instance will see that it belongs to a different runtime, and log this warning, and we will repeatedly retry launching it.

This logging existed before bug 1741156, back when content processes were the only type of child process. While we only declare one `gpu` process service (and one `socket`, one `utility`, etc), we declare many content process ones, eg `tab1`, `tab2`, etc. If gecko attempts to launch a content process and picks a service already in use then we log this warning and retry with a random `tabN` until we find one which succeeds. However, with the GPU process (and socket process, utility process, etc) this will never succeed as we've only declared one service for the process type.

I'm unsure what the consequences of this are. Perhaps we can simply remove the logging. Or perhaps we could run in to issues with failing to launch child processes. We only support multiple GeckoRuntimes during tests so it's not an issue in the wild, but perhaps it might causes issues during tests. Maybe we need to declare multiple services for each type of child process and use the same logic as for content processes to select a random service name during launch. (or perhaps even a generic `childN` services could be used for both content and non-content child processes.) Kayacan, perhaps you or somebody else on the geckoview team might be better placed to answer that?

I think what's happening here is that in xpcshell tests we create many `GeckoRuntime`s so that we can run multiple tests in parallel. Each of these runtimes attempts to launch their own GPU process but android only allows one instance of each service, in this case `org.mozilla.gecko.process.GeckoChildProcessServices$gpu`. So after the first runtime successfully launches the GPU process, each subsequent runtime attempting to do so will instead notify the existing instance we attempted to start it. The existing instance will see that it belongs to a different runtime, and log this warning, and we will repeatedly retry launching it.

This logging existed before bug 1741156, back when content processes were the only type of child process. While we only declare one `gpu` process service (and one `socket`, one `utility`, etc), we declare many content process ones, eg `tab1`, `tab2`, etc. If gecko attempts to launch a content process and picks a service already in use then we log this warning and retry with a random `tabN` until we find one which succeeds. However, with the GPU process (and socket process, utility process, etc) this will never succeed as we've only declared one service for the process type. Note that for the content processes we can encounter this warning during normal operation because multiple content processes are allowed, whereas for GPU and other process types we can only encounter it during tests due to having multiple GeckoRuntimes.

I'm unsure what the consequences of this are. Perhaps we can simply remove the logging. Or perhaps we could run in to issues with failing to launch child processes. We only support multiple GeckoRuntimes during tests so it's not an issue in the wild, but perhaps it might causes issues during tests. Maybe we need to declare multiple services for each type of child process and use the same logic as for content processes to select a random service name during launch. (or perhaps even a generic `childN` services could be used for both content and non-content child processes.) Kayacan, perhaps you or somebody else on the geckoview team might be better placed to answer that?

I think what's happening here is that in xpcshell tests we create many `GeckoRuntime`s so that we can run multiple tests in parallel. Each of these runtimes attempts to launch their own GPU process but android only allows one instance of each service, in this case `org.mozilla.gecko.process.GeckoChildProcessServices$gpu`. So after the first runtime successfully launches the GPU process, each subsequent runtime attempting to do so will instead notify the existing instance we attempted to start it. The existing instance will see that it belongs to a different runtime, and log this warning, and we will repeatedly retry launching it.

This logging existed before bug 1741156, back when content processes were the only type of child process. While we only declare one `gpu` process service (and one `socket`, one `utility`, etc), we declare many content process ones, eg `tab1`, `tab2`, etc. If gecko attempts to launch a content process and picks a service already in use then we log this warning and retry with a random `tabN` until we find one which succeeds. However, with the GPU process (and socket process, utility process, etc) this will never succeed as we've only declared one service for the process type. Note that for the content processes we can encounter this warning during normal operation because multiple content processes are allowed, whereas for GPU and other process types we can only encounter it during tests due to having multiple GeckoRuntimes.

I'm unsure what the consequences of this are. Perhaps we can simply remove the logging. Or perhaps this is an actual problem. We only support multiple GeckoRuntimes during tests so it's not an issue in the wild, but perhaps it might causes issues during tests. Maybe we need to declare multiple services for each type of child process and use the same logic as for content processes to select a random service name during launch. (or perhaps even a generic `childN` services could be used for both content and non-content child processes.) Kayacan, perhaps you or somebody else on the geckoview team might be better placed to answer that?