Zygote: Explicitly preload secondary zygote resources.
We now turn on lazy preloading (see companion change 73c7df1bda76a0)
and explicitly preload zygote resources.
To provide the most benefit :
- We start the preload in the system_server, which means the system_server
starts quicker since it has one less preload to wait for. Morever, the
64 bit zygote also starts quicker because it has one less high
priority process to contend with for CPU and I/O.
- We start the preload after the core system services start up, since we
know no 32 bit zygote processes will be requested before that point.
- We start the preload ~1s before the webview factory preparation, to
ensure that it completes before the 32 bit relro process is forked
from the zygote. In the event that it takes too long, the webview
RELRO process will block, but it will do so without holding any locks.
I have not observed this happening in > 200 runs on marlin / sailfish
devices.
This change saves about 500ms in boot times, and sometimes even more.
AFTER:
successive-online : 16970.0,16668.0,16391.0,16498.0,17601.0,16736.0,16609.0,16820.0,16310.0,17557.0,
successive-online_avg : 16816.0
successive-boot : 28750.0,29520.0,29372.0,28424.0,30683.0,28523.0,29766.0,29779.0,29304.0,31607.0,
successive-boot_avg : 29572.8
BEFORE:
successive-online : 16678.0,18105.0,17197.0,16744.0,17453.0,16946.0,18068.0,16719.0,17453.0,16942.0,
successive-online_avg : 17230.5
successive-boot : 30855.0,32069.0,31223.0,30918.0,30284.0,29750.0,31036.0,30778.0,30310.0,30908.0,
successive-boot_avg : 30813.1
Note that successive-online is a little faster, as expected since we do
less work in the 32 bit zygote.
Test: manual, timings from tradefed.
Bug: 34810190
Change-Id: I90207a2706afda163b8134ff2af31f6917f3841b
1 file changed