Garbage collection control method, chip, electronic equipment and medium
By monitoring garbage collection intervals to identify frequent GC states and improving the garbage collection waterline, the power consumption and performance issues caused by frequent GC in application processes were resolved, memory usage was optimized, and device performance was improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HONOR DEVICE CO LTD
- Filing Date
- 2024-10-25
- Publication Date
- 2026-04-28
AI Technical Summary
The power consumption and performance issues caused by frequent garbage collection in application processes, especially in foreground applications, are due to the long GC runtime and blocking of other threads, resulting in a large amount of CPU resources being consumed.
By monitoring the garbage collection interval of application processes, frequent garbage collection states can be identified, and the garbage collection waterline can be raised in these states. Garbage collection will only be performed when the heap memory usage reaches a high level, thereby reducing the number of frequent GCs and optimizing heap memory space.
It effectively reduces power consumption and performance issues in application processes by extending GC intervals, reducing CPU resource usage, optimizing memory usage, and improving device performance.
Smart Images

Figure CN121935170A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of electronic equipment technology, and in particular to a waste recycling control method, chip, electronic equipment, and medium. Background Technology
[0002] Garbage collection (GC) is an automatic memory management mechanism. When an application no longer needs to access a portion of memory, it can use GC to clean up that memory and return it to the operating system. However, frequent garbage collection by application processes can cause power consumption issues. Summary of the Invention
[0003] This application provides a garbage collection control method, chip, electronic device, and medium that can address the power consumption problem caused by frequent garbage collection in application processes.
[0004] In a first aspect, embodiments of this application provide a garbage collection control method, including: determining whether an application process is in a state of frequent garbage collection based on the interval between garbage collections performed by the application process; and raising the garbage collection waterline when the application process is in a state of frequent garbage collection.
[0005] This application embodiment can adjust the garbage collection waterline when the application process is in a state of frequent garbage collection. Raising the waterline allows garbage collection to be performed only when the application process consumes more heap memory, thus avoiding excessively frequent garbage collection and addressing the power consumption issues caused by frequent garbage collection.
[0006] Optionally, when the application process is in a state of frequent garbage collection, the garbage collection waterline is raised, including: when the application process is in a state of frequent garbage collection, determining whether a first ratio exceeds a first threshold, the first ratio being the ratio of the application process's heap memory usage to the application process's heap memory limit; if the first ratio does not exceed the first threshold, then the garbage collection waterline is raised.
[0007] By limiting the ratio of application process heap memory usage to the upper limit of heap memory to perform waterline promotion, it is possible to achieve on-demand execution of waterline promotion.
[0008] Optionally, before determining whether the application process is in a state of frequent garbage collection, the garbage collection control method further includes: the application process performing garbage collection; after the application process performs garbage collection, if the first ratio is lower than the second threshold, then the step of determining whether the application process is in a state of frequent garbage collection is executed; the first threshold is greater than the second threshold.
[0009] By limiting the ratio of application process heap memory usage to heap memory limit, waterline boosting is not supported when it is too high, thus avoiding unnecessary waterline boosting.
[0010] By limiting the ratio of application process heap memory usage to heap memory limit to a low level, support for waterline adjustment is restored, which helps to enable on-demand execution of waterline boosting.
[0011] Optionally, the waste recycling waterline can be improved by: obtaining the waterline expansion amount; and improving the waste recycling waterline based on the current value of the waste recycling waterline and the waterline expansion amount.
[0012] By adjusting the waterline based on its current value, the waterline in waste recycling can be improved, which helps to achieve adaptive improvements in the waterline.
[0013] Optionally, the waterline expansion amount can be obtained by: obtaining the remaining heap memory after garbage collection of the application process, the remaining memory of the whole machine, and the heap memory usage before and after memory compaction of the application process.
[0014] Unlike using a fixed waterline extension amount, the waterline extension amount calculated in this way is more in line with the current memory usage, thus helping to achieve accurate control over the waterline increase as needed.
[0015] Optionally, after raising the waste recycling waterline, the waste recycling control method further includes: if the application process has continuously performed at least the first number of new generation waste recyclings and has not performed old generation waste recyclings after at least the first number of new generation waste recyclings, then the type of waste recycling to be performed by the application process next is determined to be old generation waste recycling.
[0016] When an application process is in a state of frequent garbage collection, performing an old generation garbage collection after several consecutive young generation garbage collections can help optimize the application process's heap memory space.
[0017] Optionally, the determination of whether an application process is in a state of frequent garbage collection is based on the interval between garbage collections performed by the application process, including: if the application process has performed at least two garbage collections, and the interval between at least two garbage collections is less than a time threshold, and no target garbage collection with an interval greater than the time threshold has been performed during at least two garbage collections, then the application process is determined to be in a state of frequent garbage collection; wherein, the garbage collection waterline has not been raised between the target garbage collection and its previous garbage collection.
[0018] The presence of a target garbage collection indicates that the application process does not need to adjust its waterline due to frequent garbage collection. Therefore, the existence of a target garbage collection helps to accurately identify whether the application process is in a state of frequent garbage collection.
[0019] By adjusting the garbage collection waterline when the application process frequently performs garbage collection with short intervals, it is possible to achieve on-demand waterline boosting.
[0020] Secondly, embodiments of this application provide a garbage collection control device, including: a determining module, used to determine whether an application process is in a state of frequent garbage collection based on the interval time of garbage collection in the application process; and a control module, used to raise the garbage collection level when the application process is in a state of frequent garbage collection.
[0021] Thirdly, embodiments of this application provide a chip, including: a processor for executing computer program instructions stored in a memory, wherein when the computer program instructions are executed by the processor, the chip is triggered to execute the method as described in any of the first aspects.
[0022] Fourthly, embodiments of this application provide an electronic device, which includes one or more memories for storing computer program instructions and one or more processors, wherein when the computer program instructions are executed by one or more processors, the electronic device is triggered to perform the method as described in any of the first aspects.
[0023] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method as described in any of the first aspects.
[0024] In a sixth aspect, embodiments of this application provide a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform the method as described in any of the first aspects.
[0025] The technical effects of the aforementioned aspects can be referenced from each other, and will not be elaborated further here. Attached Figure Description
[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below.
[0027] Figure 1 A schematic diagram of the heap memory of an application process provided in an embodiment of this application;
[0028] Figure 2A schematic diagram illustrating how the GC thread causes other threads to block by holding a lock, as provided in an embodiment of this application.
[0029] Figure 3a This is a schematic diagram illustrating the CPU resource usage of a certain application process during garbage collection (GC) as provided in an embodiment of this application.
[0030] Figure 3b This is a schematic diagram illustrating how the execution of garbage collection (GC) by the application process affects the time taken to unlock the face.
[0031] Figure 4 A schematic flowchart illustrating a waste recycling control process provided in this application embodiment;
[0032] Figure 5 A schematic diagram illustrating how raising the GC waterline in an embodiment of this application extends the interval between GC processes.
[0033] Figure 6 This is a schematic diagram illustrating how an application process performs a Full GC after multiple consecutive Young GCs, as provided in an embodiment of this application.
[0034] Figure 7 A flowchart illustrating the process of adjusting the GC waterline is provided for an embodiment of this application.
[0035] Figure 8 A flowchart illustrating a parameter update process provided in an embodiment of this application;
[0036] Figure 9 A schematic diagram of a waste recycling control system provided in an embodiment of this application;
[0037] Figure 10 A schematic flowchart of a waste recycling control method provided in one embodiment of this application;
[0038] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;
[0039] Figure 12 This is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application. Detailed Implementation
[0040] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0041] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.
[0042] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.
[0043] It should be understood that the term "at least one" as used in this document refers to one or more, and "more than one" refers to two or more. The term "and / or" as used in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Additionally, the character " / " in this document generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0044] It should be understood that although the terms "first," "second," etc., may be used to describe the set thresholds in the embodiments of this application, these set thresholds should not be limited to these terms. These terms are only used to distinguish the set thresholds from each other. For example, without departing from the scope of the embodiments of this application, the first set threshold may also be referred to as the second set threshold, and similarly, the second set threshold may also be referred to as the first set threshold.
[0045] Garbage collection (GC) is an automatic memory management mechanism. When a portion of memory space occupied by an application is no longer accessed by that application, the application can use the GC mechanism to clean up that portion of memory space and return it to the operating system.
[0046] Feasibly, for allocated memory space, when the application process (i.e., the process of the application) no longer needs to use the memory space, the application process can trigger the GC thread to run, so as to release the memory resources occupied by the objects by destroying them, so that the memory space can be reused.
[0047] For example, the GC thread may include HeapTaskDaemon. HeapTaskDaemon is a daemon thread in the Android system used to perform memory-related tasks for applications. It monitors heap memory usage and triggers specific tasks to release memory when heap usage exceeds a certain threshold, keeping the system running healthily. Heap memory is a separate memory area from the stack, global data area, and code area. The heap allows applications to dynamically request memory space of a certain size at runtime.
[0048] See Figure 1 The maximum heap size (max size) is the maximum heap memory that can be allocated to application processes. The GC watermark corresponds to a heap size that does not exceed the maximum heap size. The GC watermark triggers a garbage collection (GC) operation when the used heap size reaches the GC watermark. The free heap size is the difference between the GC watermark and the used heap size. Application processes can continue to use available free heap memory beyond their current heap size until the used heap size reaches the GC watermark, triggering the GC thread to run.
[0049] In one embodiment, the application process can perform swap (memory switching) to compress a portion of the occupied memory. The application process's heap memory usage can then be the actual heap memory usage after the swap. Swap can refer to the exchange of data between virtual memory and physical memory.
[0050] If an application process frequently creates objects and allocates a large amount of memory, it will trigger frequent garbage collection (GC). Since GC is a process-level garbage collection mechanism, the GC process involves marking and compacting surviving objects and releasing garbage objects. To ensure consistent object access, other threads need to be paused at certain stages during the GC process, or other threads need to be blocked using locks, condition variables, or other methods.
[0051] Regarding the situation where the GC thread causes other threads to block by holding locks, see [link / reference]. Figure 2 When the GC thread of an application process acquires a lock, other threads within the application process may be blocked due to contention for the lock. Once the GC thread unlocks the lock, the other threads can successfully acquire the lock and resume execution.
[0052] Figure 3a This diagram illustrates the CPU resource usage of a specific application process during garbage collection (GC). Figure 3aAs shown, the application process frequently performs garbage collection (GC) over a period of time, and each GC consumes a significant amount of CPU resources. Because the frequent GC by the application process preempts a large amount of CPU resources, it causes power consumption issues.
[0053] Since garbage collection (GC) requires traversing reference chains to access live objects within a process, the execution time of a single GC cycle is closely related to the process's memory usage and the depth of the reference chains between objects. Compared to background processes, foreground application processes are typically in an active running state, with higher memory usage and a faster growth rate, causing the execution time of a single GC cycle for foreground applications to usually exceed 100ms.
[0054] Figure 3b This diagram illustrates how the garbage collection (GC) process performed by the application process affects the time taken to unlock the face recognition system. Figure 3b As shown, in a face unlock scenario, the face unlock process needs to perform operations such as face recognition. If the application process performs garbage collection (GC) during this period, the GC thread will preempt a large amount of CPU resources. Since GC takes a long time to run, the GC thread will preempt the large CPU cores, causing the face unlock process to run on the small and medium CPU cores. The operating efficiency of the small and medium CPU cores is lower than that of the large CPU cores, which leads to a longer face unlock time and causes performance issues. Based on the same implementation logic, other scenarios (such as payment verification scenarios) will also have the problem of frequent GC affecting device performance, which will not be exemplified here.
[0055] It is evident that because GC takes a long time to run and some stages can block the execution of other threads, if the application process frequently performs GC, it will consume a large amount of CPU resources, thereby causing power consumption and performance issues.
[0056] One embodiment of this application provides a GC control method, which can identify whether an application process is in a state of frequent garbage collection (or simply frequent GC) based on the GC interval of the application process. The GC interval of the application process is the duration between the current GC and the previous GC, such as the duration between the start time of the current GC and the end time of the previous GC.
[0057] If an application process frequently performs garbage collection (GC), it indicates that the application process is in a scenario where it frequently creates objects and allocates a large amount of memory. In this scenario, the application process's garbage collection waterline (or simply GC waterline) can be raised to avoid the application process continuously and frequently performing garbage collection.
[0058] Therefore, the waterline expansion requirement should at least include frequent garbage collection (GC) by the application process. The GC control method described above can obtain the waterline expansion amount when the application process meets the waterline expansion requirement and adjust the GC waterline accordingly. Increasing the waterline allows GC to be performed only when the application process consumes more heap memory, thus avoiding excessively frequent GC and addressing the power consumption and performance issues caused by frequent GC.
[0059] By raising the GC waterline, application processes can use more heap memory, trading memory space for performance gains. If the ratio of an application process's heap memory usage to its maximum heap memory (denoted as the first ratio) is too high, it indicates insufficient expandable memory space, preventing the application process from currently supporting GC waterline adjustments. In this case, the aforementioned waterline expansion requirement may also include the application process's current support for waterline adjustments.
[0060] If an application process does not meet the waterline expansion requirements, it can trigger a GC thread to perform garbage collection. Based on each GC cycle performed during the application process's execution, the application process's heap memory usage can change, causing the aforementioned first ratio to change accordingly. Therefore, at the end of each GC cycle, the application process's waterline support can be updated based on the current value of the first ratio, facilitating on-demand execution of waterline elevation.
[0061] It is feasible for the application process to perform either YoungGC or FullGC.
[0062] YoungGC (Young Generation Garbage Collection) refers to garbage collection that occurs in the young generation, primarily targeting the Eden and Survivor spaces. Because objects in the young generation have shorter lifecycles, YoungGC is less time-consuming than FullGC.
[0063] Full GC (Old Generation Garbage Collection) refers to garbage collection performed on the entire heap memory (including the young generation, old generation, etc.). Because it requires scanning the entire heap memory, Full GC takes longer than Young GC. Unlike Young GC, which usually does not change the original GC watermark, Full GC can recalculate a GC watermark based on the memory usage after GC.
[0064] Based on the above, in addition to adjusting the GC waterline due to frequent GC in the application process, the GC control method described above can also control the application process to perform a Full GC after several consecutive Young GCs. Since the Full GC's reclaimed region includes the Young GC's reclaimed region, and the Full GC can reset the GC waterline as needed, performing a Full GC after several consecutive Young GCs helps optimize the application process's heap memory space.
[0065] Feasibly, the aforementioned application process can run in the foreground or in the background. In one embodiment, if the application process meets the waterline expansion requirements, in addition to adjusting the GC waterline, it is also possible to request freezing (e.g., terminating) the application process running in the background, in order to address the problem of background application processes frequently creating objects and allocating large amounts of memory, thus affecting device power consumption and performance.
[0066] Below, in conjunction with Figures 4-8 The feasible specific technical implementation of the above GC control method is explained.
[0067] See Figure 4 One embodiment of this application provides a waste recycling control process, which may include the following steps 401-412. In one embodiment, Figure 4 The entity executing the process shown can be Figure 9 Virtual machine 92 is the virtual machine corresponding to application process 911, in order to support the operation of application process 911.
[0068] Step 401: The start of the i-th GC of the application process is detected. The current i-th GC (or current GC) can be any GC of the application process.
[0069] Feasibly, the application process can trigger the GC thread to run for garbage collection when the heap memory usage reaches the GC watermark. Other feasible implementations, based on on-demand GC triggering conditions, also allow the application process to actively trigger the GC thread to run when the heap memory usage has not yet reached the GC watermark but the GC triggering conditions are met.
[0070] Thus, in one embodiment, after the (i-1)th GC of the application process has finished, the virtual machine 92 can determine that the i-th GC of the application process has started when it detects that the heap memory usage of the application process has reached the GC waterline again.
[0071] After the application process starts its i-th GC, the following judgment operations 402-403 can be performed.
[0072] If step 403 determines that it is true, then step 404 can be executed to adjust the GC waterline. By adjusting the GC waterline, the application process's heap memory usage can be kept below the adjusted GC waterline, allowing the i-th GC to terminate without running. This reduces one GC run, thus avoiding the CPU resource consumption caused by GC.
[0073] If step 403 determines no, then the i-th GC runs (see step 407 below) until the i-th GC runs end.
[0074] Step 402: Based on parameter 4, determine whether the application process supports GC waterline adjustment. If yes, proceed to step 403; otherwise, proceed to step 407.
[0075] Feasibly, virtual machine 92 can have a parameter 4, the value of which can be used to indicate whether the application process supports GC waterline adjustment. For example, if the value of parameter 4 is ON or OFF, ON can indicate that the application process supports GC waterline adjustment, and OFF can indicate that the application process does not support GC waterline adjustment.
[0076] Parameter 4 can be updated by the virtual machine 92 as needed before the i-th GC, based on the comparison between ratio 1 (i.e., the ratio of the application process's heap memory usage to its heap memory limit) and the first threshold (see below). Figure 7 (See step 711 in the text). Furthermore, parameter 4 can also be updated by the virtual machine 92 as needed after the i-th GC run, based on the comparison result between the ratio 1 and the second threshold (see step 410 below, for example). The updated parameter 4 can serve as the basis for the virtual machine 92 to execute step 402 in the next iteration.
[0077] Thus, the parameter 4 obtained by virtual machine 92 when executing step 402 is based on the most recent update of parameter 4 by virtual machine 92.
[0078] Step 403: Based on parameter 1, determine whether the application process is in a frequent GC state (or simply frequent GC). If yes, proceed to step 404; otherwise, proceed to step 407.
[0079] Feasibly, a parameter 1 can be set in the virtual machine 92. The value of parameter 1 can be used to indicate the number of times the application process has recently performed GC with short intervals (or simply the number of times the application process frequently performs GC). Based on parameter 1, it can be determined whether the application process frequently performs GC.
[0080] In one embodiment, if the value of parameter 1 reaches N (i.e., if parameter 1 ≥ N), it can be determined that the application process is currently frequently garbage collecting (GC); otherwise, it can be determined that the application process is not currently frequently garbage collecting (GC). Feasibly, the value of N can be set as needed, with N ≥ 1.
[0081] Parameter 1 can be updated on demand by the virtual machine 92 after the i-th GC, based on the comparison between the interval of the i-th GC and the time threshold, and whether the i-th GC is the first GC after the last extended GC waterline (see, for example, below). Figure 8 (Steps 803 and 808 in the previous steps). The updated parameter 1 can be used as the basis for virtual machine 92 to execute step 403 in the next iteration.
[0082] Thus, the parameter 1 obtained by virtual machine 92 when executing step 403 is based on the most recent update of parameter 1 by virtual machine 92.
[0083] Step 404: Adjust the GC waterline of the application process.
[0084] Feasibly, the specific technical implementation of step 404 can be found in [reference]. Figure 7 Steps 703 to 710 in the flowchart shown will not be described in detail here.
[0085] By adjusting the GC watermark, the application process's heap memory usage can be reduced to below the adjusted GC watermark, allowing the i-th GC to terminate without needing to run, thus reducing the number of GC runs by one.
[0086] See Figure 5 After a garbage collection (GC) cycle begins, raising the GC waterline can eliminate the need for the i-th GC cycle, thus allowing for a longer interval between subsequent GC cycles. By reducing the number of GC cycles and increasing the GC interval, the CPU resource consumption of application processes due to GC execution can be reduced. See also... Figure 5 Improving the GC waterline consumes less CPU resources.
[0087] See Figure 5 and Figure 6 Between two garbage collection (GC) cycles, CPU resources are consumed not only when performing operations to raise the GC waterline, but also when performing other operations (such as the execution of other threads).
[0088] Step 405: Based on parameter 2, determine whether the most recent M consecutive GCs were all YoungGCs. If so, proceed to step 406; otherwise, proceed to step 412.
[0089] Feasibly, parameter 2 can be set in the virtual machine 92. The value of parameter 2 can be used to indicate the position of the last Full GC of the application process. Based on parameter 2, it can be determined whether the application process's most recent M consecutive GCs were all Young GCs.
[0090] Parameter 2 can be updated by the virtual machine 92 after the i-th GC, based on the comparison between the interval of the i-th GC and the time threshold, the type of the i-th GC, and whether the i-th GC is the first GC after the last GC waterline expansion (see, for example, below). Figure 8 (Steps 805, 807, and 808 in the process). The updated parameter 2 can serve as the basis for virtual machine 92 to execute step 405 in the next iteration.
[0091] Thus, the parameter 2 obtained by virtual machine 92 when executing step 405 is based on the update of parameter 2 by virtual machine 92 after running the (i-1)th GC.
[0092] Feasibly, the value of M can be set as needed, for example, it can be set to 3, etc.
[0093] Step 406: Update the type of the (i+1)th GC (i.e. the next GC) to Full GC, and then execute step 412.
[0094] See Figure 6 The application process can perform a Full GC after three consecutive Young GC cycles to reclaim the entire heap memory. Based on on-demand Full GC, not only can the application process's heap memory space be optimized, but unnecessary Full GC cycles can also avoid consuming excessive CPU resources.
[0095] Step 407, the i-th GC run.
[0096] If the application process does not meet the waterline expansion requirements, it can trigger the GC thread to run a garbage collection. After each GC run, parameters 1 to 3 can be updated, provided the application process supports GC waterline adjustment.
[0097] Feasibly, parameter 3 can be set in virtual machine 92. When the interval between the i-th GC is less than the time threshold and the GC type is Young GC, the value of parameter 3 can be used to represent the amount of memory remaining after the i-th GC of the application process (see below). Figure 8 (Step 811 in the text). Parameter 3 can be used to calculate the GC waterline expansion.
[0098] Parameter 3 can be updated on demand by the virtual machine 92 after the i-th GC, based on the comparison between the interval of the i-th GC and the time threshold, and the type of the i-th GC (see below for example). Figure 8 Step 811 in the process. The updated parameter 3 can be used as the GC waterline expansion amount for subsequent calculations in virtual machine 92 (see, for example, below). Figure 7 The basis for step 706 in the process.
[0099] Thus, the parameter 3 obtained by virtual machine 92 when executing step 706 is based on the most recent update of parameter 3 by virtual machine 92.
[0100] Step 408: Based on parameter 4, determine whether the application process supports GC waterline adjustment. If yes, proceed to step 411; otherwise, proceed to step 409.
[0101] Since the current GC operation may be due to the application process not supporting GC waterline adjustment or the application process not performing GC frequently, after the GC operation ends, parameter 4 can be used to determine whether the application process supports GC waterline adjustment. If it does, parameters 1 to 3 can be updated.
[0102] Since the execution of GC can cause changes in the heap memory usage of the application process, and the judgment result of step 408 depends on the heap memory usage after the last GC, if the judgment result of step 408 indicates that the application process does not support GC waterline adjustment, step 409 can be executed to determine whether to change the value of parameter 4 based on the current heap memory usage after GC.
[0103] Step 409: Determine if the ratio 1 is lower than the second threshold. If yes, proceed to step 410; otherwise, proceed to step 412. Ratio 1 = Application process's heap memory usage / Application process's heap memory limit.
[0104] Feasibly, the value of the second threshold can be set as needed, for example, it can be set to 0.7, etc.
[0105] Step 410: Update parameter 4 to support GC waterline adjustment for application processes.
[0106] If the result of step 409 is yes, it indicates that the current heap memory usage after GC is relatively small compared to the upper limit of heap memory, and the expandable memory space is sufficient. In this case, the value of parameter 4 can be changed to indicate that the application process supports GC waterline adjustment. If the application process supports GC waterline adjustment, parameters 1 to 3 can be updated.
[0107] Step 411: Update parameters 1 to 3, and then proceed to step 412.
[0108] Parameter 1 can be used in step 403 to determine whether the application process frequently GCs.
[0109] Parameter 2 can be used in step 405 to determine whether the most recent M consecutive GCs are all Young GCs.
[0110] See Figure 7 As shown in the process, parameter 3 can be used in step 706 to calculate the GC waterline expansion.
[0111] By updating parameters 1 to 3 in real time, accurate judgments can be made on subsequent steps such as whether to raise the GC waterline based on the updated parameters.
[0112] For a feasible implementation process of step 411, please refer to [link / reference]. Figure 8 The parameter update process shown is not described in detail here.
[0113] Step 412, GC operation ends.
[0114] In other embodiments, it is feasible to... Figure 4 The execution order of some steps in the waste recycling control process shown may vary. For example, step 403 may be executed first, followed by step 402. This application does not limit this.
[0115] In other embodiments, it is feasible to... Figure 4 The waste recycling control process shown may include more or fewer steps. For example, steps 405 to 406 may be omitted, and step 412 may be executed directly after step 404. This application does not limit this.
[0116] See Figure 7 One embodiment of this application provides a process for adjusting the GC waterline, which may include the following steps 701 to 712.
[0117] Step 701: The i-th GC of the application process has started.
[0118] Step 701 is the same as step 401, and will not be repeated here.
[0119] Step 702: Based on parameter 1, determine whether the application process is in a frequent GC state (or simply frequent GC). If yes, proceed to step 703; otherwise, proceed to step 712.
[0120] Step 702 is the same as step 403, and will not be repeated here.
[0121] If the determination in step 702 is negative, GC can be triggered by executing step 712 (see step 407 above).
[0122] Step 703: Determine whether the ratio 1 is higher than the first threshold. If not, proceed to step 704; otherwise, proceed to step 711.
[0123] Feasibly, the value of the first threshold can be set as needed, for example, it can be set to 0.9, etc.
[0124] Step 704: Calculate the multiplier factor A based on the remaining amount of total machine memory (mem_Avaliable).
[0125] Step 705: Calculate the ratio B of the heap memory usage before and after the application process performs memory compression.
[0126] For example, application processes can use swap for memory compression.
[0127] Step 706: Based on parameter 3, calculate the GC waterline expansion amount = the average amount of remaining heap memory after N GC cycles × A × B.
[0128] The GC waterline expansion is related to the amount of heap memory remaining after the application process performs GC, the amount of total machine memory remaining, and the amount of heap memory occupied before and after the application process performs memory compaction, so that the calculated GC waterline expansion is adapted to the current memory usage.
[0129] Unlike using a fixed waterline extension, the GC waterline extension calculated in step 706 is more in line with the current memory usage.
[0130] Feasibly, referring to step 403, if the value of parameter 1 reaches N, it can be determined that the application process is currently experiencing frequent GC. In this case, when expanding the GC waterline, the remaining heap memory after the corresponding N GCs can be used to calculate the GC waterline expansion amount. For updating parameter 1, see [link to update instructions]. Figure 8 Step 803 in the process.
[0131] Step 707: Determine if the application is running in the background. If yes, proceed to step 708; otherwise, proceed to step 709.
[0132] Step 708: Notify the application process to freeze, and proceed to step 709.
[0133] It is feasible to send a notification to the kernel to freeze the application process in an attempt to freeze it. The kernel can respond to this notification and freeze background application processes as needed.
[0134] Step 709, calculate the new GC waterline = min(GC waterline upper limit, the expanded GC waterline based on the GC waterline expansion amount).
[0135] Feasibly, the expanded GC waterline can be the sum of the current GC waterline and the GC waterline expansion. If the expanded GC waterline exceeds the GC waterline upper limit, then the new GC waterline can be the GC waterline upper limit. If the expanded GC waterline does not exceed the GC waterline upper limit, then the new GC waterline can be the expanded GC waterline.
[0136] Step 710: Adjust the GC waterline and proceed to step 712.
[0137] After adjusting the GC waterline, you can update the type of the next GC to Full GC as needed by executing step 712 (see steps 405-406).
[0138] Step 711: Update parameter 4 to indicate that the application process does not support GC waterline adjustment, and then proceed to step 712.
[0139] If the judgment result of step 703 is yes, it means that the current heap memory usage after GC is relatively large compared to the upper limit of heap memory, and the expandable memory space is insufficient. In this case, the value of parameter 4 can be changed to indicate that the application process does not support GC waterline adjustment.
[0140] See Figure 7 If parameter 4 is updated to indicate that the application process does not support GC waterline adjustment, GC waterline adjustment will not be performed. GC can be triggered by executing step 712 (see step 407 above).
[0141] Step 712, continue running.
[0142] In other embodiments, it is feasible to... Figure 7 The execution order of some steps in the process of adjusting the GC waterline shown may vary. For example, step 703 may be executed first and then step 702. This application does not limit this.
[0143] In other embodiments, it is feasible to... Figure 7 The process of adjusting the GC waterline shown may include more or fewer steps. For example, steps 707 to 708 may be omitted, and step 709 may be executed directly after step 706. This application does not limit this.
[0144] See Figure 8 One embodiment of this application provides a parameter update process, which may include the following steps 801 to 812.
[0145] Step 801, parameter update begins.
[0146] Once each GC cycle is complete, the parameters can be updated.
[0147] Step 802: Is the current GC interval less than the time threshold? If yes, proceed to step 803; otherwise, proceed to step 806.
[0148] Step 803: Increment parameter 1 (the number of frequent GC cycles of the application process, for example, denoted as frequent_gc_count).
[0149] If the current GC interval is short, parameter 1 can be incremented by one; if the current GC interval is long, the value of parameter 1 can remain unchanged. By updating parameter 1 as needed, it is helpful to accurately determine whether the application process is in a frequent GC state.
[0150] Step 804: Determine if the current GC is YoungGC. If yes, proceed to step 805; otherwise, proceed to step 809.
[0151] Step 805: Update parameter 2 = min(parameter 1, threshold of parameter 1), and execute step 811.
[0152] Since the current GC is YoungGC and parameter 1 has been incremented once, parameter 2 can be updated based on parameter 1.
[0153] Step 806: Based on parameter 5, determine whether the current GC is the first GC after the last extended GC waterline. If yes, proceed to step 807; otherwise, proceed to step 808.
[0154] Feasibly, virtual machine 92 can have a parameter 5, the value of which can be used to indicate whether the current GC is the first GC since the last extended GC waterline. For example, if parameter 5 is true or false, true indicates that the current GC is the first GC since the last extended GC waterline, and false indicates that the current GC is not the first GC since the last extended GC waterline. Based on parameter 5, it can be determined whether the current GC is the first GC since the last extended GC waterline.
[0155] Parameter 5 can be updated as needed by virtual machine 92 after the i-th GC, based on the comparison between the interval of the i-th GC and the time threshold (see step 807 below). The updated parameter 5 can serve as the basis for the virtual machine to execute step 806 next time. Thus, the parameter 5 obtained by virtual machine 92 when executing step 806 is based on the most recent update of parameter 5 by virtual machine 92.
[0156] See Figure 5 Assume that GC501 to GC503 are three GC cycles performed sequentially by the application process, and that the GC waterline was raised between GC501 and GC502, but not between GC502 and GC503. If the current GC is GC502, proceed to step 807. If the current GC is GC503, proceed to step 808.
[0157] Step 807: Set parameter 5 to false and update parameter 2.
[0158] Referring to steps 802 and 806, if the current GC interval is relatively long, and this GC is the first GC since the last expansion of the GC waterline, it indicates that the long interval is due to the previous increase in the GC waterline. Therefore, although the current GC interval is long, the application process still experiences frequent GC. In this case, parameter 1 is not reset to 0, so that when parameter 1 is updated as needed, it does not need to be incremented from 0 again. When the value of parameter 1 accumulates to more than N, it can be determined again that the application process is in a state of frequent GC, and the GC waterline can be adjusted again.
[0159] If parameter 5 is set to false in step 807, then when step 806 is executed again, it can be determined that the most recent GC was not the first GC after the last expansion of the GC waterline.
[0160] After updating parameter 5, parameter 2 can also be updated according to the current GC type to support the re-execution of step 405.
[0161] Step 808: Reset parameter 1 (=0), parameter 2, and parameter 3.
[0162] Referring to steps 802 and 806, if the current GC interval is relatively long, and the current GC is not the first GC after the last GC waterline expansion, it indicates that the long interval is not caused by increasing the GC waterline, but rather that the application process is not in a state of frequent GC. In this case, parameter 1 can be reset to 0. Then, when updating parameter 1 on demand, it needs to be incremented again from 0. This avoids unnecessary GC waterline adjustments, enabling on-demand execution of GC waterline adjustments.
[0163] By clearing the value of parameter 1 to zero when there is no frequent GC in the application process, the value of parameter 1 can be incremented again, which helps to accurately identify whether the application process is frequently GC.
[0164] In one embodiment, if step 806 determines no, it may indicate that the application process is not currently experiencing frequent GC, in which case parameter 2 can be reset, for example, by clearing the existing content of parameter 2.
[0165] When the value of parameter 1 is accumulated to N times, it indicates that the application process is in a state of frequent GC. In this case, the GC waterline expansion amount can be calculated based on the remaining memory after each of the N GCs provided by parameter 3. Since the determination in step 806 is negative, it indicates that the application process is not currently experiencing frequent GC, parameter 1 has been reset, and parameter 3 is not used for the next calculation of the GC waterline expansion amount. Therefore, parameter 3 can be reset in step 808, for example, by clearing the existing content of parameter 3.
[0166] Step 809: Determine if parameter 2 (the position of the last Full GC, denoted as last_full_gc_index) is greater than 0. If it is, proceed to step 810; otherwise, proceed to step 811.
[0167] Referring to step 805, the value of parameter 2 depends on the value of parameter 1. Therefore, the value of parameter 2 can be equal to 0 or greater than 0. The larger the value of parameter 2, the further away the time of the last Full GC is from the current time.
[0168] If the value of parameter 2 is greater than 0, then proceed to step 810 to update parameter 2. If the value of parameter 2 is equal to 0, no action needs to be taken to maintain the value of parameter 2 as 0.
[0169] Step 810: Update parameter 2 and proceed to step 811.
[0170] Referring to step 804, if the current GC is not YoungGC but FullGC, step 810 needs to be executed. By executing step 810, the updated parameter 2 can indicate that the position of the last FullGC is the current GC.
[0171] Step 811: Update parameter 3 (current heap memory remaining after GC = GC waterline - heap memory usage), and execute step 812.
[0172] The remaining memory after a GC is denoted as Last_gc_free_memory, the GC waterline is denoted as total_memory, and the heap memory usage is denoted as bytes_allocated. Therefore, Last_gc_free_memory = total_memory - bytes_allocated.
[0173] Referring to step 802, if the current GC interval is relatively short, increment parameter 1 by 1. When the number of increments of parameter 1 reaches N, the GC waterline expansion needs to be calculated based on the remaining memory after the current GC. Therefore, parameter 3 can be updated in step 811.
[0174] Step 812, parameter update complete.
[0175] In other embodiments, it is feasible to... Figure 8 The execution order of some steps in the parameter update process shown may vary. For example, step 811 may be executed first, followed by step 805. This application does not limit this.
[0176] In other embodiments, it is feasible to... Figure 8The parameter update process shown may include more or fewer steps. For example, the step of setting parameter 5 to false in step 807 may be omitted. This application does not limit this.
[0177] See Figure 9 One embodiment of this application provides a garbage collection control system, which may include an application 91, a virtual machine 92, and a kernel 93. The virtual machine 92 may include a GC scheduler 921, a state identification module 922, a heap memory information recording module 923, a GC information recording module 924, a GC waterline control module 925, and a GC thread 926. The kernel 93 includes memory 931.
[0178] The state recognition module 922 can be used to identify whether the application process 911 in application 91 is in a frequent GC state. Conveniently, the state recognition module 922 can be used to perform the above step 403.
[0179] The heap memory information recording module 923 can be used to record information about the application process 911's use of heap memory, such as the amount of heap memory used. The amount of heap memory used can be used to calculate the GC waterline expansion and the aforementioned ratio 1.
[0180] The GC information recording module 924 can be used to record the GC waterline of application process 911, the type of each GC performed by application process 911, etc.
[0181] The GC waterline control module 925 can be used to adjust the GC waterline of application process 911. Alternatively, the GC waterline control module 925 can be used to perform the above step 710.
[0182] The system memory information recording module 9311 in memory 931 can be used to record system memory-related information, such as the remaining amount of system memory. The remaining amount of system memory can be used to calculate the GC waterline expansion.
[0183] The GC scheduler 921 can be used to trigger the GC waterline control module 925 to adjust the GC waterline of the application process 911 when the application process 911 meets the waterline expansion requirements; and to trigger the GC thread 926 to run to perform garbage collection on the application process 911 when the application process 911 does not meet the waterline expansion requirements.
[0184] Figure 9 The specific implementation process of GC control by the waste recycling control system shown can be found in the relevant descriptions in other embodiments of this application, and will not be repeated here.
[0185] See Figure 10 One embodiment of this application provides a waste recycling control method, which may include the following steps 1001 to 1002.
[0186] Step 1001: Determine whether the application process is in a state of frequent garbage collection based on the interval between garbage collections performed by the application process.
[0187] In one embodiment of this application, step 1001 includes: if the application process has performed at least a second number of garbage collections (e.g., the above-mentioned N times), and the interval between the at least a second number of garbage collections is less than a time threshold, and no target garbage collection with an interval greater than the time threshold has been performed during the at least a second number of garbage collections, then it is determined that the application process is in a state of frequent garbage collection; wherein, the garbage collection waterline has not been raised between the target garbage collection and its previous garbage collection (i.e., no operation to raise the GC waterline has been performed during the period).
[0188] If the above parameter 1 ≥ N, it indicates that the application process is in a state of frequent GC.
[0189] It is feasible that when an application process experiences multiple garbage collections within a certain period of time, not all garbage collections will have a short interval.
[0190] See Figure 8 If step 802 determines that the condition is yes, then parameter 1 is incremented once, meaning that the current GC is one of the aforementioned at least N GCs. When parameter 1 is incremented to at least N, it can be confirmed that the application process is frequently GC-intensive.
[0191] See Figure 8 If step 806 determines no, it means that the current GC is the target garbage collection, which means that the application process is not currently performing frequent GC. In this case, N can be reset to 0 so that parameter 1 can be incremented again from zero.
[0192] See Figure 8 If step 806 determines that it is yes, it means that although the interval of the current GC is relatively long, it is actually due to the extension of the interval caused by the last increase in the GC waterline. It does not mean that the application process has escaped the scenario of frequent GC. Therefore, it will not cause parameter 1 to start accumulating from zero again, but will continue to accumulate on the existing basis.
[0193] As can be seen, the aforementioned GC events of at least N times do not necessarily have to be consecutive. For example, see [link to relevant documentation]. Figure 8 If the current GC interval is short (i.e., step 802 determines "yes"), then parameter 1 is incremented once. If the current GC interval is long and it is the first GC after the last GC waterline expansion (i.e., step 802 determines "no" and step 806 determines "yes"), then parameter 1 remains unchanged. Thus, when parameter 1 is incremented N times, even if there are GCs with long intervals during this period, the application process can still be considered to be in a frequent GC state.
[0194] Unlike identifying frequent GC status based on the total number of GCs over a period of time, identifying frequent GC status based on parameter 1 helps to accurately determine whether an application process is frequently GCd, thereby facilitating on-demand execution of waterline boosting.
[0195] A feasible way to identify whether an application process is in a frequent GC state is to refer to step 403 above.
[0196] If the application process does not perform frequent garbage collection (GC), unnecessary waterline promotion is unnecessary. Thus, the application process can perform GC once when the heap memory usage reaches the GC waterline. Therefore, in one embodiment of this application, the garbage collection control method further includes: if the application process is not in a state of frequent garbage collection, then the application process performs garbage collection.
[0197] In one embodiment of this application, before determining whether the application process is in a state of frequent garbage collection, the garbage collection control method further includes: the application process performing garbage collection; after the application process performs garbage collection, if a first ratio (e.g., the ratio 1 mentioned above) is lower than a second threshold (e.g., the second threshold in step 409), then the step of determining whether the application process is in a state of frequent garbage collection is executed. Wherein, the first threshold (e.g., the first threshold in step 703) is greater than the second threshold.
[0198] See Figure 4 If, after the last GC run, support for waterline adjustment is restored when the first ratio is low (see step 410), then after the current GC starts, step 402 can be executed to determine that the application process supports GC waterline adjustment, thereby supporting the application process to raise the GC waterline when GC is frequent.
[0199] It is evident that by limiting the ratio of application process heap memory usage to the upper limit of heap memory, restoring support for waterline adjustment can help achieve on-demand execution of waterline boosting.
[0200] Step 1002: When the application process is in a state of frequent garbage collection, raise the garbage collection waterline. The garbage collection waterline is used to trigger the application process to perform garbage collection when the heap memory usage reaches the garbage collection waterline.
[0201] This application embodiment can raise the garbage collection waterline when the application process is in a state of frequent garbage collection. Raising the waterline allows garbage collection to be performed only when the application process consumes more heap memory, thus avoiding excessively frequent garbage collection and addressing the power consumption issues caused by frequent garbage collection.
[0202] In one embodiment of this application, raising the waterline of waste recycling includes: obtaining the waterline expansion amount; and raising the waterline of waste recycling based on the current value of the waste recycling waterline and the waterline expansion amount.
[0203] It is feasible to adjust the GC waterline according to the waterline expansion amount, as can be found in step 709 above.
[0204] Compared to implementations that directly increase the GC waterline without considering its current value (such as directly increasing it to the upper limit of the GC waterline), increasing the garbage collection waterline based on its current value helps to achieve adaptive improvements to the waterline.
[0205] In one embodiment of this application, obtaining the waterline expansion amount includes: obtaining the waterline expansion amount based on the remaining heap memory after the application process performs garbage collection, the remaining memory of the entire machine, and the heap memory usage before and after the application process performs memory compression.
[0206] The formula for calculating the waterline expansion can be found in step 706 above.
[0207] In one embodiment of this application, step 1002 includes: when the application process is in a state of frequent garbage collection, determining whether a first ratio exceeds a first threshold, the first ratio being the ratio of the application process's heap memory usage to the application process's heap memory limit; if the first ratio does not exceed the first threshold, then raising the garbage collection waterline.
[0208] By limiting the ratio of application process heap memory usage to heap memory limit, waterline adjustment is not supported when it is too high, thus avoiding unnecessary waterline boosting.
[0209] By limiting the ratio of application process heap memory usage to the upper limit of heap memory to perform waterline adjustment, it is possible to achieve on-demand execution of waterline boosting.
[0210] In one embodiment of this application, after raising the garbage collection waterline, the garbage collection control method further includes: if the application process has performed at least the first number (e.g., M times as mentioned above) of young generation garbage collections consecutively, and has not performed old generation garbage collections after at least the first number of young generation garbage collections, then the type of garbage collection to be performed by the application process next is determined to be old generation garbage collection. This helps to optimize the heap memory space of the application process.
[0211] Figure 10 The specific technical implementation of the illustrated embodiment can be found in the relevant descriptions in other embodiments of this application, and will not be repeated here.
[0212] The method provided in any embodiment of this application can be applied to electronic devices such as mobile phones, tablets, personal digital assistants (PDAs), desktops, laptops, notebook computers, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, and wearable devices. This application does not impose any special limitations on the specific form of the aforementioned electronic devices.
[0213] The waste recycling control method provided in any embodiment of this application can be applied to... Figure 11 In the electronic device 100 shown. Figure 11 A schematic diagram of the structure of the electronic device 100 is shown.
[0214] Electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.
[0215] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
[0216] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.
[0217] In some embodiments, the processor 110 may be a system-on-chip (SoC), which may include a central processing unit (CPU), and may further include other types of processors. In some embodiments, the processor 110 may be a PWM control chip.
[0218] The processor 110 may also include necessary hardware accelerators or logic processing hardware circuitry, such as an ASIC, or one or more integrated circuits for controlling the execution of the program. Furthermore, the processor 110 may have the capability to operate one or more software programs, which may be stored in a storage medium.
[0219] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.
[0220] In some embodiments, the memory of the electronic device 100 may be a read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), or other types of dynamic storage devices capable of storing information and instructions. It may also be an electrically erasable programmable read-only memory (EEPROM), or any computer-readable medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer.
[0221] In some embodiments, the processor 110 and the memory can be combined into a single processing device, or they can be separate components. The processor 110 can be used to execute program code stored in the memory. In specific implementations, the memory can be integrated into the processor 110, or it can be independent of the processor 110.
[0222] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.
[0223] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.
[0224] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.
[0225] In addition, the electronic device runs an operating system on top of the aforementioned components. For example... operating system, operating system, Operating systems, etc. Applications can be installed and run on an operating system.
[0226] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of electronic device 100.
[0227] Figure 12 This is a software structure block diagram of an electronic device 100 according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into multiple layers, from top to bottom: application layer, application framework layer (Framework, FWK), system library and runtime layer, hardware abstraction layer (HAL), and kernel layer.
[0228] The application layer can include a series of application packages, such as camera, gallery, calendar, calling, map, navigation, WLAN, Bluetooth, music, video, SMS and other applications.
[0229] The application framework layer provides an Application Programming Interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 12As shown, the application framework layer may include a view system, notification manager, resource manager, window manager, content provider, etc.
[0230] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.
[0231] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating the device, and flashing indicator lights.
[0232] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.
[0233] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.
[0234] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.
[0235] The system library and runtime layer includes the system library and the Android Runtime.
[0236] System libraries can include multiple functional modules. For example: 3D graphics processing libraries (e.g., OpenGL ES), surface managers, 2D graphics engines (e.g., SGL), media libraries, etc.
[0237] The 3D graphics processing library is used for 3D graphics drawing, image rendering, compositing, and layer processing. The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications, such as OpenGL ES. The 2D graphics engine is a drawing engine for 2D graphics, such as SGL. The media library supports playback and recording of various common audio and video formats, as well as still image files. The media library supports various audio and video encoding formats, such as: Moving Picture Experts Group (MPEG4), High-Compression Digital Video Codec Standard (H.264), Moving Picture Experts Compression Standard Audio Layer 3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate Codec (AMR), Joint Picture Experts Group (JPG), Portable Web Graphics (PNG), etc.
[0238] The Android runtime consists of the core libraries and the virtual machine. The Android runtime is responsible for scheduling and managing the Android system. The core libraries comprise two parts: one part contains the functionalities that Java calls, and the other part is the core Android library itself. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.
[0239] The Hardware Abstraction Layer (HAL) acts as a bridge between software and hardware. It encapsulates the underlying hardware driver, providing a generic interface for the application framework to call the driver. The HAL is an abstract interface for the device kernel driver, providing application programming interfaces (APIs) for accessing the underlying device to higher-level Java API frameworks. The HAL contains multiple library modules, each implementing an interface for a specific type of hardware component. The HAL provides APIs for higher-level Java API frameworks to access the underlying device; when an API framework requests access to the electronic device's hardware, the Android system loads the corresponding library module for that hardware component.
[0240] The kernel layer is the layer between hardware and software. It contains at least camera drivers, display drivers, Bluetooth drivers, audio drivers, and sensor drivers. The kernel layer is the foundation of the Android system, through which the system's final functionalities are implemented.
[0241] Understandable, Figure 12 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer layers than illustrated, and each layer may include more or fewer components; this application does not impose any limitations.
[0242] This application also provides a garbage collection control device, including: a determination module, used to determine whether the application process is in a state of frequent garbage collection based on the interval time of garbage collection in the application process; and a control module, used to raise the garbage collection level when the application process is in a state of frequent garbage collection.
[0243] This application also provides a chip, which is installed in an electronic device. The chip includes a processor for executing computer program instructions stored in a memory, wherein when the computer program instructions are executed by the processor, the chip is triggered to execute the method steps provided in any method embodiment of this application.
[0244] This application also proposes a terminal device, which includes a communication module, a memory for storing computer program instructions, and a processor for executing the program instructions. When the computer program instructions are executed by the processor, the terminal device is triggered to execute the method steps provided in any method embodiment of this application.
[0245] This application also proposes a server device, which includes a communication module, a memory for storing computer program instructions, and a processor for executing the program instructions. When the computer program instructions are executed by the processor, the server device is triggered to execute the method steps provided in any method embodiment of this application.
[0246] This application also provides an electronic device, which includes multiple antennas, a memory for storing computer program instructions, a processor for executing the computer program instructions, and a communication device (such as a communication module that can implement 5G communication based on the NR protocol). When the computer program instructions are executed by the processor, the electronic device is triggered to execute the method steps provided in any method embodiment of this application.
[0247] Specifically, in the embodiments of this application, one or more computer programs are stored in the aforementioned memory, and the one or more computer programs include instructions that, when executed by the aforementioned device, cause the aforementioned device to perform the method steps described in the embodiments of this application.
[0248] Furthermore, the devices, apparatuses, and modules described in the embodiments of this application may be implemented by computer chips or physical entities, or by products with certain functions.
[0249] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.
[0250] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.
[0251] Specifically, this application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to execute the method steps provided in this application.
[0252] This application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform the method steps provided in this application.
[0253] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.
[0254] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0255] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.
[0256] An integrated unit implemented as a software functional unit can be stored in a computer-readable storage medium. This software functional unit, stored in a storage medium, includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.
[0257] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0258] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0259] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments of this application can be implemented using electronic hardware, computer software, or a combination of electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0260] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the same or similar parts between the various embodiments of this application can be referred to mutually. For example, the specific working processes of the systems, devices, and units described in the embodiments of this application can be referred to the corresponding processes in the method embodiments of this application, and will not be repeated here.
[0261] The above description is merely a specific embodiment of this application and is not intended to limit this application. The scope of protection of this application shall be determined by the claims.
Claims
1. A waste recycling control method, characterized in that, include: Based on the interval between garbage collection by the application process, determine whether the application process is in a state of frequent garbage collection; When the application process is in a state of frequent garbage collection, raise the garbage collection level.
2. The method according to claim 1, characterized in that, When the application process is in a state of frequent garbage collection, raise the garbage collection waterline, including: When the application process is in a state of frequent garbage collection, it is determined whether the first ratio exceeds the first threshold. The first ratio is the ratio of the application process's heap memory usage to the application process's heap memory limit. If the first ratio does not exceed the first threshold, then the waste recycling water level is raised.
3. The method according to claim 2, characterized in that, Before determining whether the application process is in a state of frequent garbage collection, the method further includes: The application process performs garbage collection; After the application process performs garbage collection, if the first ratio is lower than the second threshold, then the step of determining whether the application process is in a state of frequent garbage collection is executed. The first threshold is greater than the second threshold.
4. The method according to claim 1, characterized in that, The water line for improving waste recycling includes: Get the waterline expansion amount; Based on the current value of the waste recycling water line and the water line expansion amount, raise the waste recycling water line.
5. The method according to claim 4, characterized in that, The acquisition of waterline expansion includes: The waterline expansion amount is obtained based on the remaining heap memory after garbage collection of the application process, the remaining total memory, and the heap memory usage before and after memory compression of the application process.
6. The method according to claim 1, characterized in that, After the water line for waste recycling is raised, the method further includes: If the application process has performed at least one number of young generation garbage collections and has not performed any old generation garbage collections since the first number of young generation garbage collections, then the type of garbage collection to be performed by the application process next is determined to be old generation garbage collection.
7. The method according to any one of claims 1-6, characterized in that, Determining whether an application process is in a state of frequent garbage collection based on the interval of garbage collection during application processes includes: If the application process has performed at least two garbage collections, and the interval between the at least two garbage collections is less than a time threshold, and no target garbage collection with an interval greater than the time threshold has been performed during the at least two garbage collections, then the application process is determined to be in a state of frequent garbage collection. The water level for waste recycling has not been raised between the target waste recycling and its previous waste recycling.
8. A chip, characterized in that, include: A processor for executing computer program instructions stored in memory, wherein when the computer program instructions are executed by the processor, the chip is triggered to perform the method as described in any one of claims 1-7.
9. An electronic device, characterized in that, The electronic device includes one or more memories for storing computer program instructions and one or more processors, wherein when the computer program instructions are executed by the one or more processors, the electronic device is triggered to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1-7.
11. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1-7.