While investigating bug 1623518, I wrote a script that parses the JSComponentLoader logs from Android's logcat prints out which scripts are cached and which are slow loaded in each of the parent and the child processes.

In fenix, I discovered that 7 of the 12 scripts slow loaded in the child process on COLD start up (from loading example.com) are already loaded from cache in the parent process:

--- N/A: PARENT-CACHED-INTERSECT-CHILD-SLOW 7 ---
{'resource:///actors/ContentDelegateChild.jsm',
 'resource:///actors/GeckoViewContentChild.jsm',
 'resource:///actors/ProgressDelegateChild.jsm',
 'resource://gre/modules/ConduitsChild.jsm',
 'resource://gre/modules/ExtensionTelemetry.jsm',
 'resource://gre/modules/PerformanceCounters.jsm',
 'resource://gre/modules/PromiseUtils.jsm'}

It seems like there is a bug that is preventing us from getting full use of the cache in the child process.

It's strange that scripts that seem explicitly targeted to the child process, like ContentDelegateChild, are loading in the parent at all in fenix. In this case, it appears the child slow loads it first:

02-15 10:42:24.003 19308 19343 I Gecko   : [Child 19308: Main Thread]: D/JSComponentLoader Slow loading resource:///actors/ContentDelegateChild.jsm
02-15 10:42:24.511 19242 19264 I Gecko   : [Parent 19242: Main Thread]: D/JSComponentLoader Successfully loaded resource:///actors/ContentDelegateChild.jsm from cache

I can't reproduce the issue as significantly on geckoview_example:

--- N/A: PARENT-CACHED-INTERSECT-CHILD-SLOW 1 ---
{'resource://gre/modules/E10SUtils.jsm'}

I guess geckoview_example doesn't run into this behavior – where the parent loads scripts intended for the child.

My guess would be that the parent is loading it so that it could be cached for the child the next time we start. I might be wrong, though.

I spoke with :agi and we learned that, because we load web extensions in the parent process, the background extension page imports some of these *Child.jsm files. I think this is unintended behavior so I filed bug 1755581.

The core issue in this bug is that the child process is slow loading the scripts that seem to be cached when read from the parent process. However, since the parent process (probably) shouldn't be loading these scripts at all (like in geckoview_example), I think we can ignore the state of the parent process. We're left with the scripts not being cached in the child process. I think the reason these scripts aren't cached on subsequent runs is bug 1468673: i.e. that we need to widen the window where we're choosing to cache scripts.

I think the actionable work of this bug are captured in the two other bugs so I'm going to close this.

(In reply to Michael Comella (:mcomella) [needinfo or I won't see it] from comment #3)

The core issue in this bug is that the child process is slow loading the scripts that seem to be cached when read from the parent process. However, since the parent process (probably) shouldn't be loading these scripts at all (like in geckoview_example), I think we can ignore the state of the parent process.

I don't think that the scripts being loaded in the parent is part of the problem here. It is fairly common for child scripts to load in the parent process, since we have to be able to load web pages in the parent process (at least on desktop) and don't want to have multiple codepaths to support it.

But the script preloader knows how to deal with that. It tags each script with the process types it is known to load in, and splits the cache images into one for scripts needed only in the parent, and one for scripts needed in the child. The parent loads both images, and reads scripts from the child image as needed. If the child process tells the parent process that it has loaded a given script that has also been loaded by the parent, that script goes into the child image rather than the parent image, and the child has access to it on subsequent runs.

So the problem is likely just that we aren't getting a complete list of scripts needed by the child in GeckoView.