The goal is to reduce amount of work renderer does when it starts loading a page. See attached screenshot where warmed up renderer spent 150ms loading libraries, 140ms of which was spent in NativeLibraryPreloader.loadLibrary(). This is on 1GiB Android Go device (gobo @  OMB1.171105.001).

Since preloading doesn't need to know command line arguments, we can preload early, once service is bound (and library process type is known).

Implementation: https://chromium-review.googlesource.com/c/chromium/src/+/757561

With preloading renderer spends ~100ms less on library loading.

Memory impact is reasonable: +160KiB of private dirty and +1741KiB of PSS, see attached meminfo dumps.

Deleted: no_preloading-trace.html.gz 1.3 MB

no_preloading-trace.html.gz 1.3 MB Download

Deleted: no_preloading-meminfo.txt 68.7 KB

no_preloading-meminfo.txt 68.7 KB View Download

Deleted: preloading-trace.html.gz 1.4 MB

preloading-trace.html.gz 1.4 MB Download

Deleted: preloading-meminfo.txt 68.8 KB

preloading-meminfo.txt 68.8 KB View Download

Deleted: no_preloading.png 27.0 KB

	no_preloading.png 27.0 KB View Download

Deleted: preloading.png 11.3 KB

	preloading.png 11.3 KB View Download

Preloading only benefits warmed up child processes, if a child process is started in response to a request, there is no difference in the amount of work to load libraries, the work is just differently distributed (NativeLibraryPreloader is called from loadAlreadyLocked() vs called before loadAlreadyLocked()).

Deleted: preloading_cold.png 6.3 KB

	preloading_cold.png 6.3 KB View Download

Deleted: no_preloading_cold.png 9.6 KB

	no_preloading_cold.png 9.6 KB View Download

Deleted: preloading_cold-trace.html.gz 2.7 MB

preloading_cold-trace.html.gz 2.7 MB Download

Deleted: no_preloading_cold-trace.html.gz 2.7 MB

no_preloading_cold-trace.html.gz 2.7 MB Download

Thick line at the left in all screenshots above is "NavigationTiming navigationStart".

Hi,

Something that I don't quite understand intuitively is why the CPU duration is significantly lower than the task duration to load the library. Since this is done close to startup, loading the native library should not require any major page faults, as it was loaded a few seconds earlier for the browser process.

So loading the library should be CPU-bound, meaning that we are actually getting descheduled here. In this case, doing more work earlier in the renderer process could actually slow things down by taking CPU time from it.

Have you looked at time to commit for instance, to check that we don't regress?

I've ran 50 times with/without preloading, and the results are too noisy to tell anything: https://docs.google.com/a/chromium.org/spreadsheets/d/1zFazntCMlo0gC9reQoUB1iAaeSAfAZDSywgNPd809Os/edit?usp=sharing

I think we land this and then monitor perf bots / UMA, because logically this change should have positive impact.

BTW, this is preloading, which simply calls android_dlopen_ext() [1], and doesn't run JNI_OnLoad. So it shouldn't touch many code pages (I believe we still have few global objects and other things that run during dlopen).


[1] https://cs.corp.google.com/android/frameworks/base/native/webview/loader/loader.cpp?l=128

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6857926630a26ae40009d7cf014970f717ffd56

commit e6857926630a26ae40009d7cf014970f717ffd56
Author: Dmitry Skiba <dskiba@chromium.org>
Date: Fri Nov 17 20:09:35 2017

Preload native library when child process is bound.

Library loading is the first thing that happens when a renderer starts
navigating to a page. NativeLibraryPreloader is called during loading
and is responsible for majority of the loading time. However, unlike
library loading, preloading doesn't need to know command line of the
child process, and thus can happen earlier.

This CL preloads libraries when a child process is bound, which speeds
up navigation for warmed up renderers.

Bug:  783913 
Change-Id: I3bffdc613717bfc61e038a2525cd96c5d0f0c0c3
Reviewed-on: https://chromium-review.googlesource.com/757561
Commit-Queue: Dmitry Skiba <dskiba@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517527}
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/base/android/java/src/org/chromium/base/library_loader/NativeLibraryPreloader.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/base/android/java/src/org/chromium/base/process_launcher/ChildProcessServiceDelegate.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/base/android/java/src/org/chromium/base/process_launcher/ChildProcessServiceImpl.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/base/test/android/java/src/org/chromium/base/MultiprocessTestClientServiceDelegate.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/content/public/android/java/src/org/chromium/content/app/ContentChildProcessServiceDelegate.java
[modify] https://crrev.com/e6857926630a26ae40009d7cf014970f717ffd56/content/shell/android/shell_apk/src/org/chromium/content_shell_apk/TestChildProcessService.java