1753541 - Self-hosted script cache is never used for content process start up in fenix

Status: RESOLVED DUPLICATE of bug 1618391

(Core :: XPConnect, defect, P3)

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

When executing a cold start up in fenix nightly 2/3 with a VIEW intent (i.e. opening a link from an external app; adb shell am start -a android.intent.action.VIEW -d 'apple.com' -n org.mozilla.fenix/org.mozilla.fenix.IntentReceiverActivity), the JS::InitSelfHostedCode method for the first content process always seems to call into js::frontend::CompileGlobalScriptToStencil rather than using the cache (the xdrCache argument). The code comments suggest this cache can be used across multiple executions so I think it should be possible to use here. See these profiles from separate start ups as a demonstration (note: I did a warm up run and waited 60s before checking this behavior (which usually allows various gecko caches to initialize and be used on the subsequent run)):

• https://share.firefox.dev/3HtxL6f (apple.com redirects to https://www.apple.com)
• https://share.firefox.dev/3L6gZwh (no redirect)

Impact

js::frontend::CompileGlobalScriptToStencil runs between 65 and 90ms in these profiles on a Moto G5. The cached version would probably be (*hand-wave*) 5-10ms so we're looking at a 55-80ms improvement in total time to start the content process.

However, we will not receive the benefit if starting the content process is not the bottleneck. I'm not sure what the bottleneck is though. It could be that we're usually waiting on a response from the network request started in the parent process. However, it's difficult to measure a realistic scenario right now due to bug 1734916 where the network request is blocked on a UI transition. For that reason, if we make a patch, we may not be able to measure the improvement in COLD VIEW right now (though maybe it can be measured when opening a content process in an active browser session).

In either case, I expect this to be an improvement to power usage.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Hmm.

I think the place to investigate would be around here; it seems like this relies on the parent process having filled in the shared memory and then having the child successfully read it. If something is going wrong with this shmem on android, that would explain why we're not seeing this benefit there.

Comment 2

[Nicolas B. Pierron [:nbp]]

The initial work to add the IPC glue to share the self-hosted XDR from the parent process to its children was done as part of Bug 1698045.

Unfortunately, due to CI issues reporting Timeouts (Bug 1615203). To avoid blocking desktop work behind a non-longer intermittent, the work from Bug 1698045 got split to extract its Android part Bug 1710884.

I would be happy to revive Bug 1710884, that this bug is likely a duplicate of, as soon as Bug 1615203 is unblocked.

Unfortunately, I have no understanding of Android IPC and my patch is mostly copying what is already in place. Thus finding a person who would know how to address this Timeout issue is the blocking issue right now.

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Nicolas, would you consider this a dupe of bug 1618391? Thanks for the information.