tree 14fec386051bdcb0569aeb18342326900219a66c
parent 2f8ad4bc3284358575aad06822cac1650512cb1b
author Mathieu Chartier <mathieuc@google.com> 1495667650 -0700
committer Lokesh Gidra <lokeshgidra@google.com> 1517442259 -0800

Do fewer GCs shortly after zygote fork

After zygote fork, increase heap limit (max_allowed_footprint_)
to maximum growth limit and concurrent GC threshold (concurrent_start_bytes_)
to half of heap limit for 2s. This means there will be, most likely, no GCs
that happen during launch for most apps. This should reduce startup time
of apps, as well as, save some power.

After the 2s windows is done, a concurrent GC is done to free up
RAM and adjust the counters back to normal, if no GC took place
so far.

Not measured: Boot time, transient RAM usage increase.

-----------------------------------------------------
App     | Avg speed     | Heap size       | GC count
-----------------------------------------------------
Camera  | 567ms / 588ms |  4.3MB / 2.7MB  | 2 / 4
-----------------------------------------------------
Chrome  | 350ms / 394ms |  2.5MB / 1.5MB  | 0 / 2
-----------------------------------------------------
Photos  | 447ms / 516ms |    6MB / 4MB    | 0 / 3
-----------------------------------------------------
Maps    |1419ms / 1440ms| 19.5MB / 11MB   | 0 / 5
-----------------------------------------------------
Gmail   | 148ms / 156ms |  3.5MB / 2.5MB  | 0 / 1
-----------------------------------------------------
Youtube | 721ms / 761ms |    8MB / 4.5MB  | 0 / 3
-----------------------------------------------------
Notes:
1) Format: <with change / without change>
2) For Camera app, 2 GCs are caused by native allocations
3) Speed is averaged over 100 runs
4) Heap size is at end of the launch

Bug: 36727951
Test: test-art-host
Change-Id: I4ca9b5be7433097851560f8738fbc8cae733d85e