Sorry, you need to enable JavaScript to visit this website.

Optimize Garbage Collector Parameters for High Memory in Chrome* OS-ARC++

BY Jaishankar Rajendran, Biboshan Banerjee ON May 24, 2021


A Chromebook* is a laptop or tablet running the Linux*-based Chrome OS as its operating system. This product became very popular when Android* apps were made available on Chromebooks via the Google* Play application distribution platform. As the sales of Chromebooks have increased year-over-year, improving the Android User Experience has become a key criterion. [1]

The ChromeOS ARC++ (Android running as container) stack has been optimized to balance memory usage and performance by default. On high-memory devices, the ChromeOS ARC++ stack should leverage the available memory to it fullest potential to increase performance.

Our work aims to provide an improved experience by improving the launch time and user experience of Android applications by optimizing heap parameters for x86 Chromebook platforms.

Our results show an improvement of ~6.5% in Janky frames of graphics benchmarks and ~10% and ~17.5% improvement in cold launch time and warm launch time, respectively, for apps in various app segments in 8G configuration. For 16G configuration, there was an improvement of ~15.5% in Janky frames, ~9% and ~15.5% improvement in cold launch time and warm launch time, respectively, for apps in various app segments.


It is essential that Chromebooks leverage the available hardware in the most efficient manner to deliver an excellent user experience to end users.

Chromebooks in the current market are available with high onboard memory. This high onboard memory allows us to further optimize the various memory parameters, which leads to improved performance.

By utilizing the memory in Chromebooks more efficiently, Chromebooks are able to perform their tasks faster and better, and execute workloads better.


Android uses a generational heap, meaning that its memory allocations are divided into multiple buckets, which it tracks based on the size and expected lifetime of the object being allocated.

For example, recently allocated objects belong in the Young generation. When an object stays active long enough, it can be promoted to an older generation, followed by a permanent generation.

Each heap generation has its own dedicated upper limit on the amount of memory that objects there can occupy. Any time a generation starts to fill up, the system executes a garbage collection (GC) event in an attempt to free up memory. The duration of the GC depends on which generation of objects it is collecting and how many active objects are in each generation.

Even though garbage collection can be quite fast, it can still affect an app's performance [2]. Given the availability of higher RAM sizes, GC cost can be reduced by giving more free memory after every GC cycle. The garbage collector in Android runtime (ART) is called Concurrent Copying (CC) collector. It requires that there are virtual address space reservations for two “halves” of the heap, only one of which is shown in Figure 1. The first contains the active heap and contains some allocated memory. The second (inactive) half of the heap virtual address space is reserved address space but is not used for allocations. Except during collections, only the active “half” is backed by physical memory.

Figure 1: Space reservation of the heap

The current configuration for dalvik heap parameters in ARC++ is assumed that the device has 2G memory. Recently, Android devices are built with higher memory and the heap parameters need to be configured to match this high memory configuration. We derived new values for heap parameters for 8G and 16G configurations based on Google’s AOSP patches and our experiments.

The dalvik heap parameters we have set are:

  • dalvik.vm.heapstartsize
  • dalvik.vm.heapgrowthlimit
  • dalvik.vm.heapsize
  • dalvik.vm.heaptargetutilization
  • dalvik.vm.heapminfree
  • dalvik.vm.heapmaxfree


With 8G parameters, the results are a reduction of ~6.5% in Janky frames for Android graphic benchmarks. We were also able to bring down the cold launch time by ~10% and reduce the warm launch time by ~17.5% for productivity, audio/video streaming, social, gaming, content creation, and conference segment apps.

With 16G parameters the results are a reduction of ~15.5% in Janky frames for Android graphic benchmarks.. We were also able to bring down the cold launch time by ~9% and reduce warm launch time by ~15.5% for productivity, audio/video streaming, social, gaming, content creation, and conference segment apps.


GC terminology

Figure 2 illustrates the important concepts for the garbage collector’s computations based on the use of memory. The heap starts out with a virtual address space reservation of heap max size. Within this reservation, there is a limit on the maximum size of the process’ heap, called the heap growth limit. Within that reservation there is the heap size (H), which is the amount of memory that is currently considered in the heap. Some of the memory is in use by clients of the GC, and this is called the live size (L). What remains of H is the free memory, of free size (F). There are two variables that control the GC behavior at the time of application start. The first sets the initial heap size in the Zygote, which all application processes inherit. The second sets the heap max size for the process.

  • dalvik.vm.heapstartsize

The initial heap size H an application process is given at startup.

  • dalvik.vm.heapsize

The heap max size that an application process can use. This is a hard limit on the maximum heap size of any process in the system.

Figure 2: Heap growth limit

Per computations during the GC, we compute the live bytes L in the heap and the heap size H is updated according to the following formula:

H = L + max{ min{M, L * (1 / U − 1)}, m)} * S

Five variables control the computation of the new heap size that is performed at the end of each GC event. The first four control M, m, U, and S. The last specifies the initial heap growth limit. Where M and m are the maximum and minimum free bytes in the resulting heap, U is the target utilization of the heap, and S is the foreground heap multiplier. This ratio determines the amount of memory that a foreground application can allocate. The value S indicates the current multiplier and defaults to 3.0 for foreground and 1.0 for background applications. [3]



Heap Parameters


dalvik.vm.heapmaxfree (M)

The maximum amount of free memory, in bytes, allowed after a GC event.

dalvik.vm.heapminfree (m)

The minimum amount of free memory, in bytes, allowed after a GC event.

dalvik.vm.heaptargetutilization (U)

The fraction of the heap that should be live after a GC event.

dalvik.vm.foreground-heap-growth-multiplier (S)

GC parameters are weighted by whether an application is in the foreground state or in the background.


The initial limit on the maximum size of a heap (G). An application can request that G be as large as the heap max size by specifying a large heap in its manifest or by calling clearGrowthLimit. clearGrowthLimit may only be called once. An app can reduce the maximum heap size to G by calling clampGrowthLimit. If this is called explicitly the virtual address allocation for the heap is trimmed to G as well.

Table 1: Heap parameters and their definitions.

After studying the garbage collectors’ computations, heap parameters, and the parameters for 4G and 6G, we were able to derive the parameters for 8G and 16G, which are shown in Table 2.


Dalvik VM Parameters

Default (2G)



























Table 2: Dalvik VM parameters for 2G, 8G and 16G



Our evaluation platform is a Dell* ChromeBook, with an Intel® Core™ i7-10610U processor with 4 cores, 8 threads. The processor base frequency is 400 MHz and can reach up to 4.9 GHz in Turbo mode. The memory available in the device is 16 GB. The latest ChromeOS version R83 with Android P is loaded in the device. We have ensured that “Internet Speed Test” is executed before collecting the data to confirm that the internet bandwidth is the same during execution of the tests.

To test the Dalvik VM parameter, we collect the Janky frames of Graphics Benchmarks:

  • 3D Mark Sling Shot Extreme
  • GFX Benchmark: T-Rex Onscreen, T-Rex Offscreen, Manhattan Onscreen, and Manhattan Offscreen.

We collected the Janky frames using the dumpsys functionality.

We also collected the cold and warm app launch times of apps from productivity, audio, video streaming, social, gaming, content creation and conference segments.

Figure 3: Janky frames performance comparison between the default, 8G, and 16G parameters.


Figure 4: Cold launch time performance comparison between the default, 8G and 16G parameters.


Figure 5: Warm launch time performance comparison between the default, 8G and 16G parameters.

Google has accepted the heap parameters for 8G and 16G and performed their validation and observed ~4% gain in 8Gb and ~6% gain in 16G chromebooks for ARC Boot metrics.

These Changes were merged to Chrome OS by Google, they are available from Chrome OS Version R89.0.4343.0.13654.0.0

Figure 6: High Memory Option in Chrome OS


Given the availability of higher RAM sizes in present devices, setting the Dalvik VM parameter to higher values gives us good performance improvement. With the above data, we see good improvements with these configurations in the reduction of Janky frames and launch times. The improvements we have achieved with the parameters of 8G and 16G are in line with the improvements Google has published in their document for 4G and 8G parameters. We can publish both these configurations and by default we can safely set 8G configuration for Chromebooks with 16G RAM.

Email us to ask questions or discuss issues:,,

About the authors

This article was written by Jaishankar Rajendran and Biboshan Banerjee.

Jaishankar Rajendran is a member of the CCG Chrome PnP Architecture Team.

Biboshan Banerjee is a member of the Android Ecosystem Engineering Department at Intel Technology India Pvt. Ltd. Thanks to Mohan Murali and Sajal K Das for their support and guidance.

Notices and disclaimers

Tests document performance of components on a particular test, in specific systems. Differences in hardware, software, or configuration will affect actual performance. Consult other sources of information to evaluate performance as you consider your purchase. For more complete information about performance and benchmark results, visit

Performance results are based on testing as of dates shown in configurations and may not reflect all publicly available ​updates. See backup for configuration details. No product or component can be absolutely secure. Your costs and results may vary. Intel technologies may require enabled hardware, software or service activation.

© 2021 Intel Corporation. Intel, the Intel logo, Intel Core, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others. ​


Test configuration

Software: Android 9.0, OpenGL ES 3.1 Mesa Support

Hardware: Dell Chromebook, Intel® Core™ i7-10610U processor, 4 Core 8 Threads, 16 GB Ram

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at





"Overview of memory management," 24 02 2021. [Online]. Available:


Android High-memory Configurations.