Android ART Memory Management via Hot-Cold Method Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Android operating system's memory management is inefficient due to continuous loading of code segments from dex and oat files, leading to increased memory consumption as more programs run, with existing methods for recording method information in profile files needing optimization to reduce memory usage.
Innovation Solution
A method is introduced to classify method information based on invocation frequency using adjustable thresholds, allowing for accurate release of memory occupied by infrequently used code by determining the start and end addresses of hot and cold methods, thereby optimizing memory usage without disrupting program smoothness.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If code segments from dex and oat files are continuously loaded into memory as programs run, then program execution functionality is maintained, but memory consumption increases continuously
Solution Approach 1:
The patent segments the code space by dividing methods into hot methods (frequently invoked) and cold methods (infrequently invoked) based on invocation counting. This segmentation allows differential memory management where hot methods remain loaded while cold methods can be released, thus reducing overall memory consumption while maintaining program execution functionality.
Solution Approach 2:
The patent changes the parameter of method invocation frequency by introducing a counting mechanism. Methods are monitored and classified based on their invocation count thresholds, transforming the static memory loading approach into a dynamic one where memory allocation varies based on actual usage patterns.
2Loss of time
If method information is recorded to profile file for AOT compilation, then program startup speed is improved, but memory usage increases due to loading more code
Solution Approach 1:
The patent applies partial action by performing AOT compilation selectively only on hot methods rather than all methods. The system identifies frequently invoked methods through profiling and compiles only those to native code, achieving startup speed improvement for critical paths without the memory overhead of compiling and loading entire dex files.
Solution Approach 2:
The patent uses preliminary profiling action to identify hot methods before AOT compilation. By first monitoring method invocation frequencies and recording them in profile files, the system prepares information that guides subsequent selective compilation, ensuring that only necessary code is pre-compiled and loaded into memory.
3Quantity of substance
If Dexlayout centralizes hot spot code and maps less code to memory, then memory occupation is optimized, but method information recording needs further optimization
Solution Approach 1:
The patent implements feedback mechanisms through invocation counting and profiling. The system continuously monitors method invocation frequencies, updates profile files with this feedback information, and uses this data to dynamically adjust which methods are classified as hot or cold, thereby optimizing memory occupation adaptively.
Solution Approach 2:
The system performs self-service by automatically profiling and classifying methods based on their own invocation patterns. The ART runtime monitors its own execution, counts invocations, and autonomously determines which methods should be kept in memory versus released, reducing the need for external intervention or complex manual configuration.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
This application provides a method for collecting information. The method includes: when a quantity of times of invoking a target method in a running lifecycle of a target program increases, obtaining, based on a method identifier of the target method, the quantity of times of invoking the target method; and recording method information of the target method based on the quantity of times of invoking the target method, a first threshold, and a second threshold, and setting a method status of the target method, where the method status is used to indicate a status of the method invoked by the target program and corresponding to the method status, the method status is a first state or a second state, the first state corresponds to the first threshold, the second state corresponds to the second threshold, the first threshold and the second threshold are positive integers, and the second threshold is greater than 0 and less than the first threshold.