Binder-driven memory management method, device, equipment, and storage medium

Abstract

The present application discloses a Binder-driven memory management method, apparatus, device, and storage medium, wherein the method includes: obtaining a Binder inter-process communication instruction initiated by a first process to a second process; in response to the Binder inter-process communication instruction, requesting a memory recycling list to allocate a target memory space for storing communication data to the first process and the second process; in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, requesting a preset memory pool to allocate a target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system. In this way, the present application can improve the memory allocation speed in Binder inter-process communication.

Description

Technical Field

[0001] The present application relates to the technical field, and in particular to a Binder-driven memory management method, apparatus, device, and storage medium. Background Art

[0002] The entire Android system architecture makes extensive use of the Binder mechanism as an inter-process communication (IPC) solution. In the Android system, each application is composed of one or more of Android's four major components: Activity, Service, Broadcast, and ContentProvider. These components involve a large amount of inter-process communication, all of which relies on the Binder IPC mechanism.

[0003] During inter-process communication, when the "data sending process" wants to send data to the "data receiving process," the Binder driver requests a physical memory buffer to store the communication data. The Binder driver preferentially requests the target memory space for communication data from the BinderAlloc LRU list. If the Binder Alloc LRU list runs low on free memory, it must continue to request memory from the buddy system. If the buddy system runs low on free memory, it must reclaim pages to ensure allocation, resulting in slower memory allocation. Summary of the Invention

[0004] A first aspect of the present application provides a Binder-driven memory management method, comprising: obtaining a Binder inter-process communication instruction initiated by a first process to a second process; in response to the Binder inter-process communication instruction, requesting a memory recycling list to allocate a target memory space for storing communication data to the first process and the second process; in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, requesting a preset memory pool to allocate a target memory space to the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system.

[0005] The second aspect of the present application provides a Binder-driven memory management device, including: an acquisition module, used to obtain a Binder inter-process communication instruction initiated by a first process to a second process; a first allocation module, used to allocate a target memory space for storing communication data to the first process and the second process from the system's memory recycling list in response to the Binder inter-process communication instruction; a second allocation module, used to allocate a target memory space for storing communication data to the first process and the second process from a preset memory pool in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, wherein the preset memory pool is a portion of the memory space allocated from the partner system.

[0006] A third aspect of the present application provides an electronic device, which includes a memory and a processor coupled to each other, wherein the memory is used to store program data, and the processor is used to execute the program data to implement the aforementioned method.

[0007] A fourth aspect of the present application provides a computer-readable storage medium, in which program data is stored. When the program data is executed by a processor, it is used to implement the aforementioned method.

[0008] The beneficial effects of the present application are as follows: Different from the prior art, the present application obtains the Binder inter-process communication instruction initiated by the first process to the second process, and then responds to the Binder inter-process communication instruction, requests the memory recycling list to allocate target memory space for storing communication data for the first process and the second process; in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, requests the preset memory pool to allocate target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system. In the above scheme, a preset memory pool is proposed for the Binder-driven memory allocation framework. The preset memory pool is independent of the memory recycling list and the partner system. When the free memory space in the memory recycling list is insufficient, the target memory space that should be requested from the partner system is adjusted to the target memory space that is requested from the preset memory pool. This can avoid the situation where the partner system is short of memory and needs to ensure memory allocation through memory recycling, thereby improving the memory allocation speed in Binder inter-process communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of this application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be derived from these drawings without inventive effort. Among them:

[0010] Figure 1 This is a diagram of the memory allocation process of the Binder IPC native solution;

[0011] Figure 2 This is a schematic diagram of the target memory space application and release process during the Binder inter-process communication process of this application;

[0012] Figure 3 This is a flow chart of an embodiment of the Binder-driven memory management method of the present application;

[0013] Figure 4 This is a flow chart of another embodiment of the Binder-driven memory management method of the present application;

[0014] Figure 5 yes Figure 3 A flow chart of an embodiment of step S12;

[0015] Figure 6 This is a flowchart of another embodiment of the Binder-driven memory management method of the present application;

[0016] Figure 7 This is a schematic block diagram of the structure of an embodiment of the Binder-driven memory management device of the present application;

[0017] Figure 8 This is a schematic block diagram of the structure of an embodiment of the electronic device of the present application;

[0018] Figure 9 This is a schematic structural block diagram of an embodiment of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0019] References to "embodiments" in this application mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0020] The terms "first" and "second" in this application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0021] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0022] Performance is undoubtedly a crucial factor for users of electronic devices. The Binder IPC mechanism offers superior performance compared to traditional process communication methods like pipes, message queues, and sockets. For example, Binder IPC requires only one copy of data (in shared memory), while traditional process communication methods like pipes, message queues, and sockets require two.

[0023] The entire Android system architecture makes extensive use of the Binder mechanism as an IPC solution. In the Android system, each application is composed of one or more of Android's four major components: Activity, Service, Broadcast, and ContentProvider. These components involve extensive inter-process communication, all of which relies on the Binder IPC mechanism. Therefore, optimizing the Binder IPC mechanism will undoubtedly significantly improve the performance of mobile devices.

[0024] See also Figure 1 , Figure 1 This is a diagram of the memory allocation process of the Binder IPC native solution.

[0025] First, before inter-process communication, the application can implement memory mapping with the driver by calling the mmap() system function. In the Binder driver, a virtual memory buffer (up to 4M) in the kernel space is allocated through the virtual memory size passed in from the user space. This virtual memory buffer is mapped to an address in the user space, and the user program can communicate between processes through this address. Figure 1 As shown in the figure, before inter-process communication, the Binder driver has allocated a virtual memory buffer for the second process. At this time, the Binder driver does not allocate physical memory. The Binder driver applies for memory when it is needed to avoid memory waste.

[0026] Then, when the first process wants to send data to the second process, the Binder driver will apply for a physical memory buffer area (i.e., the target memory space) from the kernel space to store the communication data, and then call copy_from_user() to copy the data to the target memory space in the kernel (Binder driver). At this time, the first process will be suspended. Since the mapping relationship has been established before the inter-process communication, this is equivalent to sending the communication data to the user space of the second process. Then the Binder driver notifies the server-side process to perform the unpacking.

[0027] Then, after receiving the Binder driver notification, the second process unpacks the communication data and calls the relevant methods for processing. After the processing is completed, it issues a free buffer instruction to release the target memory space. Of course, the second process also returns the processing results to the first process. The process is equivalent to the reverse process above, so I will not repeat it here.

[0028] Finally, when the upper-level process (representing at least one of the first process and the second process) exits the inter-process communication (that is, the inter-process communication is interrupted), or the upper-level process actively initiates the release buffer instruction, or the upper-level process initiates the free buffer instruction after the communication is completed, the binder driver will also release the target memory space.

[0029] See also Figure 2 , Figure 2 This is a flow chart of the target memory space application and release process during the Binder inter-process communication process.

[0030] The target memory space is requested as follows:

[0031] When the first process initiates the Binder inter-process communication instruction for the first time and requests the Binder driver to allocate the target memory space for storing the communication data, it must apply for the target memory space from the partner system based on the Binder driver memory allocation framework. When the communication is completed, the target memory space will be released to the Binder Alloc LRU linked list. Among them, the Binder Alloc LRU linked list (hereinafter referred to as the LRU linked list) is the linked list for releasing memory from the Binder native cache. The memory space in the LRU linked list corresponds to the process of inter-process communication. Only when the communicating process releases the target memory space to the LRU linked list after the communication is completed, the memory space corresponding to the communicating process will exist in the LRU linked list.

[0032] In order to minimize the shock caused by memory reclamation, the memory that has just been reclaimed needs to be reallocated because it is accessed again immediately. Linux designed the LRU (Last Recent Use) linked list to prioritize the reclaiming of memory that has not been accessed for the longest time. The function of the LRU linked list is to sort pages, placing the memory pages that should be reclaimed at the end of the linked list and the memory pages that should not be reclaimed at the head of the linked list. Memory reclamation mainly dumps the data in the tail memory pages that are rarely accessed recently in the LRU linked list from memory to disk, and then releases the dumped memory pages to the partner system, or directly releases the memory pages to the partner system without dumping them for use as free memory.

[0033] When the first process initiates a Binder inter-process communication instruction for the first time and requests the Binder driver to allocate a target memory space for storing communication data, the Binder driver will first apply for the target memory space from the Binder Alloc LRU list. If the LRU list cannot find the corresponding target memory space, it will then apply for the target memory space from the partner system. When the first process applies for the target memory space from the LRU list, the LRU list can only allocate the free memory space corresponding to the first process and the second process, but cannot allocate the memory space of other processes to the first process and the second process. There are two situations in which the LRU list cannot find the corresponding target memory space. The first is that the memory space corresponding to the first process and the second process does not exist in the LRU list. The second is that the memory space corresponding to the first process and the second process in the LRU list is insufficient, that is, the memory space corresponding to the first process and the second process is smaller than the target memory space.

[0034] When the memory space corresponding to the first process and the second process in the memory allocation linked list is insufficient, the target memory space is requested from the partner system.

[0035] Correspondingly, the target memory space is released as follows:

[0036] The first one is that when the upper-level process (representing at least one of the first process and the second process) exits the inter-process communication (that is, the inter-process communication is interrupted), or the upper-level process actively initiates the release buffer instruction, the Binder driver directly releases the target memory space back to the partner system.

[0037] The second is that the upper-layer process initiates a free buffer instruction after the communication is completed, and the binder driver releases the target memory space back to the LRU linked list.

[0038] Based on the current Binder-driven memory allocation framework, there are two situations where slow memory allocation may occur:

[0039] 1. When a process initiates binder communication for the first time, the memory space corresponding to the process does not exist in the LRU list. Therefore, the target memory space must be requested from the partner system. As a result, the partner system may need to guarantee allocation through page recycling due to insufficient memory of its own, resulting in a low memory allocation speed.

[0040] 2. When the process does not initiate binder communication for the first time, but the system is short of memory, the pages in the LRU list will be released to the partner system, so it is still necessary to apply for the target memory space from the partner system, resulting in a low memory allocation speed.

[0041] Based on this, this application provides a Binder driver memory management method, adjusts the original Binder driver memory allocation framework, and proposes a preset memory pool. Please refer to the subsequent embodiments for details.

[0042] See also Figures 3 and 4 , Figure 3 This is a flow chart of an embodiment of the Binder-driven memory management method of the present application. Figure 4 This is a flow chart of another embodiment of the Binder-driven memory management method of the present application, wherein the execution subject of the present application is an electronic device.

[0043] The method may include the following steps:

[0044] Step S11: Obtain a Binder inter-process communication instruction initiated by the first process to the second process.

[0045] Step S12: In response to the Binder inter-process communication instruction, a request is made to the memory recycling linked list to allocate a target memory space for storing communication data for the first process and the second process.

[0046] Among them, the memory recycling list is the Binder Alloc LRU list, which is created during system initialization. The kernel uses a bidirectional linked list to define the LRU list, and is divided into LRU_ANON (anonymous list) and LRU_FILE (file mapping page list) according to the page type. Each type is divided into active LRU and inactive LRU according to the activity of the page. Therefore, there are a total of five LRU lists in the kernel: LRU_INACTIVE_ANON (inactive anonymous page list), LRU_ACTIVE_ANON (active anonymous page list), LRU_INACTIVE_FILE (inactive file mapping page list), LRU_ACTIVE_FILE (active file mapping page list), and LRU_UNEVICTABLE (unreclaimable page list).

[0047] Specifically, the binder_update_page_range() function is used to request the memory recycling linked list to allocate a target memory space for storing communication data for the process of inter-process communication, and map it to the virtual memory address space of the kernel state and the user state respectively.

[0048] Step S13: In response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, a request is made to a preset memory pool to allocate target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system.

[0049] Specifically, the binder_page_poool_alloc_pages() function can be called to request the preset memory pool (also known as Binder PagePool) to allocate target memory space for the first process and the second process. The size of the predicted memory pool can be set according to actual conditions and is not limited here. The memory space managed by the predicted memory pool is smaller than the memory space managed by the partner system. Furthermore, the memory space managed by the predicted memory pool may be much smaller than the memory space managed by the partner system. For example, the memory space managed by the predicted memory pool is 8M, and the memory space managed by the partner system is 8G or 12G. It can be seen that using an 8M preset memory pool is very little for electronic devices with 8G or 12G running memory, but it can largely avoid the binder driver allocating physical memory to the partner system, taking a slow path, causing user process blocking and other problems.

[0050] Among them, the binder_page_poool_alloc_pages() function is used to request the preset memory pool to allocate target memory space for the process of inter-process communication.

[0051] In some embodiments, in response to the free memory space corresponding to the first process and the second process in the memory reclaim list being insufficient to store communication data, it can be in response to the absence of free memory space corresponding to the first process and the second process in the memory reclaim list, or the free memory space corresponding to the first process and the second process in the memory reclaim list being smaller than the target memory space, requesting the preset memory pool to allocate the target memory space for the first process and the second process.

[0052] The memory space in the LRU linked list corresponds to the inter-process communication process. Only when the inter-process communication process releases the target memory space to the LRU linked list after the communication is completed, there will be free memory space corresponding to the inter-process communication process in the LRU linked list. Therefore, when the first process initiates the Binder inter-process communication instruction to the second process for the first time, there is no free memory space corresponding to the first and second processes in the LRU linked list.

[0053] Among them, when there is free memory space corresponding to the first process and the second process in the LRU linked list, but the free memory space is smaller than the target memory space, it means that the LRU linked list is insufficient to allocate the target memory space for the first process and the second process, and thus it is necessary to request from the preset memory pool. Generally, when the free memory space corresponding to the first process and the second process in the LRU linked list is insufficient to store communication data, the target memory space is requested to be allocated from the partner system. However, this application changes the original memory allocation mechanism and sets an intermediate preset memory pool between the partner system and the LRU linked list, thereby eliminating the need to request the target memory space from the partner system.

[0054] The above scheme obtains the Binder inter-process communication instruction initiated by the first process to the second process, and then responds to the Binder inter-process communication instruction, requests the memory recycling list to allocate target memory space for storing communication data for the first process and the second process; in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, requests the preset memory pool to allocate target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system. In the above scheme, a preset memory pool is proposed for the Binder-driven memory allocation framework. The preset memory pool is independent of the memory recycling list and the partner system. When the free memory space in the memory recycling list is insufficient, the target memory space that should be requested from the partner system is adjusted to the target memory space that is requested from the preset memory pool. This can avoid the situation where the partner system is short of memory and needs to use memory recycling to ensure memory allocation, thereby improving the memory allocation speed in Binder inter-process communication.

[0055] See also Figure 5 , Figure 5 yes Figure 3FIG. 1 is a flow chart of an embodiment of step S12 in FIG.

[0056] In this embodiment, step S12 may include sub-steps S121 to S123:

[0057] Step S121: In response to the Binder inter-process communication instruction, apply for target memory space from the memory recycling list.

[0058] Step S122: determining the free memory space corresponding to the first process and the second process in the memory recycling linked list, wherein the memory recycling linked list is used to reclaim the memory space released after the communication of at least one group of communication processes is completed.

[0059] Step S123: In response to the free memory space corresponding to the first process and the second process in the memory recycling linked list being greater than or equal to the target memory space, the target memory space is allocated to the first process and the second process from the memory recycling linked list.

[0060] In a specific example, the free memory space corresponding to the first process and the second process in the memory recycling linked list is 0.2M, and the target memory space is 0.1M, so the target memory space is allocated to the first process and the second process from the memory recycling linked list.

[0061] See also Figure 4 and Figure 6 , Figure 6 This is a flow chart of another embodiment of the Binder-driven memory management method of the present application.

[0062] The method may include the following steps:

[0063] Step S21: Obtain a Binder inter-process communication instruction initiated by the first process to the second process.

[0064] Step S22: In response to the Binder inter-process communication instruction, a request is made to the memory recycling list to allocate a target memory space for storing communication data for the first process and the second process.

[0065] Step S23: In response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, a request is made to a preset memory pool to allocate target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system.

[0066] For the description of steps S21 to S23, please refer to the aforementioned embodiment and will not be repeated here.

[0067] Step S24: In response to the free memory space in the preset memory pool being insufficient to store the communication data, requesting the partner system to allocate target memory space for the first process and the second process.

[0068] In some implementations, the memory space managed by the preset memory pool includes both the occupied memory space allocated to other processes for communication and the unallocated free memory space. Therefore, when the target memory space requested by the first process is larger than the current free memory space, the preset memory pool cannot allocate the target memory space for the first and second processes, and the target memory space must be requested from the partner system.

[0069] In some embodiments, when the amount of free memory in the preset memory pool is less than a preset threshold, a request can be made to the partner system to allocate memory space to the preset memory pool until the amount of free memory in the preset memory pool reaches the preset threshold. Furthermore, when the amount of free memory in the preset memory pool exceeds the preset threshold, the free memory space exceeding the preset threshold can be reclaimed to the partner system. Thus, in one example, the preset memory pool can always maintain 8MB of free memory space, so that the free memory space in the preset memory pool can meet the target memory space allocation.

[0070] It should be noted that, in this embodiment, steps S24 to S28 are not necessarily performed in a sequential order. The steps can be performed sequentially or simultaneously, which is not limited here.

[0071] Step S25: in response to a reclaim instruction for the memory space in the memory reclaim linked list, reclaim the memory space to be reclaimed in the memory reclaim linked list to a preset memory pool.

[0072] Among them, when the partner system is short of memory, a recycling instruction for the memory space in the memory recycling list will be generated. In some technical solutions, the recycling instruction is used to recycle the memory space to be reclaimed in the memory recycling list to the partner system, but in this embodiment, in response to the recycling instruction, the memory space to be reclaimed in the memory recycling list is preferentially recycled to the preset memory pool.

[0073] Specifically, when the partner system is short of memory, the physical memory is reclaimed through the callback driver function shrink().

[0074] The memory space to be reclaimed can be free memory space in the memory reclaim list, or inactive memory space in the occupied memory space, that is, memory space that has not been accessed within a preset time range. The specific memory space to be reclaimed can be set or adjusted according to actual conditions and is not limited here. Optionally, the preset time range can be 2 hours, 1 day, etc., and can be set or adjusted according to actual conditions and is not limited here.

[0075] Step S26: In response to the free memory amount in the preset memory pool being greater than the preset threshold, the remaining memory space to be reclaimed in the memory reclaiming linked list is reclaimed to the partner system.

[0076] Optionally, the preset threshold value can be set or adjusted according to actual conditions and is not limited here. In one example, the preset threshold value can be the total memory capacity of the preset memory pool (such as 8M), or 80% to 90% of the total memory capacity (such as 6.4M to 7.2M).

[0077] Specifically, the free_page() function may be called to reclaim the remaining memory space to be reclaimed in the memory reclaim list to the partner system, so as to increase the system memory space.

[0078] Step S27: In response to the interruption of the inter-process communication between the first process and the second process, the target memory space is released and the target memory space is recycled to a preset memory pool.

[0079] The interruption of the inter-process communication between the first process and the second process may be that at least one of the first process and the second process exits, specifically, the process is killed by the system or is actively closed by the user.

[0080] In some embodiments, in response to the interruption of inter-process communication between the first process and the second process, a release buffer() function may be called to release the target memory space, and then a binder_page_pool_free_pages() function may be called to reclaim the target memory space to a preset memory pool. The binder_page_pool_free_pages() function is used to reclaim the memory space released when the inter-process communication is interrupted to the preset memory pool.

[0081] In some embodiments, in response to the amount of free memory in the preset memory pool being greater than a preset threshold, at least a portion of the target memory space released when the inter-process communication is interrupted is reclaimed to the partner system. For an explanation of the preset threshold, see step S26 and will not be repeated here.

[0082] Step S28: In response to the completion of the inter-process communication between the first process and the second process, the target memory space is released and the target memory space is recycled to the memory recycling linked list.

[0083] In some implementations, in response to completion of inter-process communication between the first process and the second process, free buffer() may be called to release the target memory space, and then the list_lru_add() function may be called to reclaim the target memory space to the memory reclaim list.

[0084] Among them, free buffer() is used to release the target memory space in the kernel space when the inter-process communication is completed; release buffer() is used to release the target memory space in the kernel space when the inter-process communication is interrupted; list_lru_add() is used to add the target memory space released by free buffer() to the LRU linked list.

[0085] This application optimizes physical memory allocation for the Binder process communication driver module, effectively resolving performance issues caused by slow physical memory allocation during Binder communication, which can lead to blocked user threads. Testing has shown that on Android mobile devices, this optimization solution can reduce Binder physical memory allocations from entering the slow path by 90% and reduce application frame drops by 5%.

[0086] See also Figure 7 , Figure 7 This is a schematic structural diagram of an embodiment of a Binder-driven memory management device of the present application.

[0087] The Binder-driven memory management device 100 includes an acquisition module 110, a first allocation module 120, and a second allocation module 130. The acquisition module 110 is used to acquire a Binder inter-process communication instruction initiated by a first process to a second process; the first allocation module 120 is used to, in response to the Binder inter-process communication instruction, request a memory recycling list to allocate a target memory space for storing communication data for the first and second processes; and the second allocation module 130 is used to, in response to the free memory space corresponding to the first and second processes in the memory recycling list being insufficient to store the communication data, request a preset memory pool to allocate a target memory space for the first and second processes, wherein the preset memory pool is independent of the memory recycling list and the partner system.

[0088] In some embodiments, in response to a Binder inter-process communication instruction, a request is made to a memory recycling linked list to allocate a target memory space for storing communication data to the first process and the second process, including: in response to the Binder inter-process communication instruction, applying for the target memory space from the memory recycling linked list; determining the free memory space corresponding to the first process and the second process in the memory recycling linked list, wherein the memory recycling linked list is used to reclaim the memory space released after communication between at least one group of communication processes is completed; in response to the free memory space corresponding to the first process and the second process in the memory recycling linked list being greater than or equal to the target memory space, allocating the target memory space to the first process and the second process from the memory recycling linked list.

[0089] In some embodiments, the second allocation module 130 is specifically used to: in response to the absence of free memory space corresponding to the first process and the second process in the memory reclaim list, or the free memory space corresponding to the first process and the second process in the memory reclaim list is smaller than the target memory space, request the preset memory pool to allocate the target memory space for the first process and the second process.

[0090] In some embodiments, the second allocation module 130 is further configured to: in response to the free memory space in the preset memory pool being insufficient to store the communication data, request the partner system to allocate target memory space for the first process and the second process.

[0091] In some embodiments, the Binder-driven memory management device 100 further includes a recycling module (not shown) for recycling the memory space to be reclaimed in the memory recycling list to a preset memory pool in response to a recycling instruction for the memory space in the memory recycling list.

[0092] In some embodiments, the recycling module is further configured to reclaim the remaining memory space to be reclaimed in the memory recycling linked list to the partner system in response to the amount of free memory in the preset memory pool being greater than a preset threshold.

[0093] In some embodiments, the recycling module is further configured to release the target memory space and reclaim the target memory space to a preset memory pool in response to interruption of inter-process communication between the first process and the second process.

[0094] For the description of the above steps, please refer to the aforementioned method embodiment and will not be repeated here.

[0095] See also Figure 8 , Figure 8 This is a schematic structural block diagram of an embodiment of the electronic device of the present application.

[0096] The electronic device 200 includes a memory 210 and a processor 220 coupled to each other. The memory 210 is used to store program data, and the processor 220 is used to execute the program data to implement the steps in any of the above method embodiments.

[0097] The electronic device 200 may include, but is not limited to, personal computers (e.g., desktops, laptops, tablets, PDAs, etc.), mobile phones, servers, wearable devices, augmented reality (AR), virtual reality (VR) devices, televisions, etc., without limitation here.

[0098] Specifically, the processor 220 is used to control itself and the memory 210 to implement the steps in any of the above method embodiments. The processor 220 can also be called a central processing unit (CPU). The processor 220 may be an integrated circuit chip with signal processing capabilities. The processor 220 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 220 can be implemented by multiple integrated circuit chips.

[0099] See also Figure 9 , Figure 9 This is a schematic structural block diagram of an embodiment of a computer-readable storage medium of the present application.

[0100] The computer-readable storage medium 300 stores program data 310 . When the program data 310 is executed by a processor, it is used to implement the steps in any of the above method embodiments.

[0101] The computer-readable storage medium 300 can be a medium that can store computer programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. It can also be a server that stores the computer program. The server can send the stored computer program to other devices for execution, or it can also execute the stored computer program itself.

[0102] As described above, the term "and / or" in this application is merely a description of an association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can represent three situations: the existence of A alone, the existence of both A and B, and the existence of B alone. Furthermore, the term "at least one" in this application represents any combination of at least two of any one or more of a plurality of items. For example, "at least one of A, B, and C" can represent any one or more elements selected from the set consisting of A, B, and C.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation methods described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0104] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0105] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0106] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0107] The above description is merely an embodiment of the present application and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A Binder-driven memory management method, characterized in that: include: Obtain the Binder inter-process communication instruction initiated by the first process to the second process; In response to the Binder inter-process communication instruction, requesting a memory recycling linked list to allocate a target memory space for storing communication data for the first process and the second process; In response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, a request is made to a preset memory pool to allocate the target memory space for the first process and the second process, wherein the preset memory pool is independent of the memory recycling list and the partner system.

2. The method according to claim 1, wherein The step of requesting, in response to the Binder inter-process communication instruction, to allocate target memory space for storing communication data to the first process and the second process from a memory recycling linked list includes: In response to the Binder inter-process communication instruction, applying for the target memory space from the memory recycling linked list; Determine the free memory space corresponding to the first process and the second process in the memory recycling linked list, wherein the memory recycling linked list is used to reclaim the memory space released after communication between at least one group of communication processes is completed; In response to the free memory space corresponding to the first process and the second process in the memory reclaiming linked list being greater than or equal to the target memory space, the target memory space is allocated to the first process and the second process from the memory reclaiming linked list.

3. The method according to claim 1, wherein In response to the free memory space corresponding to the first process and the second process in the memory recycling linked list being insufficient to store the communication data, requesting a preset memory pool to allocate the target memory space for the first process and the second process includes: In response to the absence of free memory space corresponding to the first process and the second process in the memory reclaim list, or the free memory space corresponding to the first process and the second process in the memory reclaim list is smaller than the target memory space, the preset memory pool is requested to allocate the target memory space for the first process and the second process.

4. The method according to claim 1, wherein The method comprises: In response to the free memory space in the preset memory pool being insufficient to store the communication data, a request is made to the partner system to allocate the target memory space for the first process and the second process.

5. The method according to claim 1, wherein The method further comprises: In response to a reclaim instruction for the memory space in the memory reclaim linked list, the memory space to be reclaimed in the memory reclaim linked list is reclaimed to the preset memory pool.

6. The method according to claim 5, characterized in that The method further comprises: In response to the free memory amount in the preset memory pool being greater than a preset threshold, the remaining memory space to be reclaimed in the memory reclaiming linked list is reclaimed to the partner system.

7. The method according to claim 1, wherein The method further comprises: In response to the interruption of inter-process communication between the first process and the second process, the target memory space is released and the target memory space is reclaimed to the preset memory pool.

8. A Binder-driven memory management device, characterized in that: include: An acquisition module is used to obtain a Binder inter-process communication instruction initiated by the first process to the second process; A first allocation module is configured to allocate target memory space for storing communication data for the first process and the second process from a memory recycling linked list of the system in response to the Binder inter-process communication instruction; A second allocation module is configured to allocate target memory space for storing the communication data to the first process and the second process from a preset memory pool in response to the free memory space corresponding to the first process and the second process in the memory recycling list being insufficient to store the communication data, wherein the preset memory pool is independent of the memory recycling list and the partner system.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor coupled to each other, the memory is used to store program data, and the processor is used to execute the program data to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores program data, and when the program data is executed by a processor, it is used to implement the method according to any one of claims 1 to 7.

Images