Memory management method and device, storage medium and computer equipment

Abstract

The invention provides a memory management method and device, a storage medium and computer equipment, and aims to realize object granularity memory allocation and release by maintaining fine-grained and shareable access memory management metadata on a separated memory and allowing an application client to directly and concurrently access the metadata. The problem of memory occupation expansion in the existing memory management technology is solved. Moreover, the leakability and accessibility of the distributed object are actively maintained in the memory management process, so that the overhead of traversing an object graph like a garbage collection mechanism is prevented from being introduced in the memory leak recovery process.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a memory management method, apparatus, storage medium, and computer device. Background Technology

[0002] In a disaggregated memory (DM) architecture, memory management (MM) serves as the fundamental way for applications to use disaggregated memory on demand, providing both memory management and memory release operations. Memory management allows applications to allocate memory when needed and release it after use, thus avoiding unnecessary occupation of disaggregated memory. Existing memory management methods employ a two-level management strategy. Specifically, memory nodes implement coarse-grained memory management, providing fixed-size memory blocks to compute nodes. Compute nodes then implement fine-grained memory management, further dividing memory blocks into objects using systems such as SLAB allocation.

[0003] However, while existing management strategies can allocate and release memory, there may be situations where the released memory cannot be used by other clients, leading to a serious problem of fragmented memory usage expansion under real workloads. Summary of the Invention

[0004] In view of this, this application provides a memory management method, apparatus, storage medium, and computer device to solve the problem of memory bloat in existing memory management technologies and improve memory utilization efficiency.

[0005] Specifically, this application is implemented through the following technical solution:

[0006] In a first aspect, embodiments of this disclosure provide a memory management method, including:

[0007] After generating a memory access request, each unallocated object is determined based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated.

[0008] If the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, then a target tree node is selected from the tree nodes and its node metadata is modified according to the node metadata of each tree node in each buddy tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a buddy tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a buddy tree correspond to different memory spaces;

[0009] The second memory space corresponding to the target tree node is divided into multiple objects, and each target object that matches the size of the first memory space is selected from the multiple objects.

[0010] The target object is allocated to the memory access request, and the object metadata of each object corresponding to the target tree node is maintained in the memory node.

[0011] In one possible implementation, the root node of a sibling tree corresponds to a memory space of a maximum preset size; the sibling nodes in the tree node are obtained by uniformly dividing the memory space corresponding to the parent node; the leaf nodes in the tree node are memory pages with a target size.

[0012] The node metadata of each tree node in the partner tree is stored in a contiguous array in the order of subsequent traversal of each tree node.

[0013] In one possible implementation, the step of selecting a target tree node from the various tree nodes and modifying the node metadata of the target tree node based on the node metadata of each tree node in each buddy tree maintained by the memory node includes:

[0014] Each of the partner trees is traversed, and for the currently traversed partner tree, the target level in the partner tree is determined according to the first memory space.

[0015] Based on the node metadata of each candidate tree node located in the target level, determine from the partner tree whether there is an initial tree node that can be assigned;

[0016] If so, based on the modification result of the node metadata of the initial tree node, determine whether to use the initial tree node as the target tree node.

[0017] In one possible implementation, determining whether to use the initial tree node as the target tree node based on the modification result of modifying the node metadata of the initial tree node includes:

[0018] If the modification result indicates that the modification was successful, then obtain the ancestor tree nodes and descendant tree nodes of the initial tree node in the partner tree;

[0019] If the node metadata of each ancestor tree node and each descendant tree node indicates that it is not assigned, the initial tree node shall be used as the target tree node.

[0020] In one possible implementation, the method further includes:

[0021] If the node metadata of each ancestor tree node and each descendant tree node contains node metadata indicating that it has been allocated, then it is determined that the initial tree node cannot be used as the target tree node, and the modification of the node metadata of the initial tree node is cancelled.

[0022] Alternatively, if the modification result indicates that the modification failed, it is determined that the initial tree node cannot be used as the target tree node.

[0023] In one possible implementation, the method further includes:

[0024] If the initial tree node does not exist in the currently traversed partner tree, or if it is determined that the initial tree node cannot be used as the target tree node, then continue traversing the next partner tree until the target tree node is determined.

[0025] In one possible implementation, determining the target level in the buddy tree based on the first memory space includes:

[0026] Determine the dimensions of the object;

[0027] The third memory space is determined based on the object partition size, the reserved space for each object, and the first memory space;

[0028] Based on the third memory space and the target space size, the corresponding target level in the buddy tree is determined.

[0029] In one possible implementation, determining from the partner tree whether an initial tree node that can be allocated exists, based on the node metadata of each candidate tree node located at the target level, includes:

[0030] The memory boundary is determined based on the memory space size corresponding to any randomly selected candidate tree node, and the tree node to be used is selected according to the memory boundary; the memory boundary is used to indicate the tree nodes that can be selected.

[0031] If, based on the node metadata of the tree node to be used, it is determined that the tree node to be used cannot be used as the initial tree node, then the number of times the tree node to be used has been selected is determined.

[0032] If the number of attempts reaches the target number, the memory boundary is expanded by a preset multiple to obtain a new memory boundary; the target number is determined based on the number of tree nodes indicated by the memory boundary.

[0033] Return to the step of selecting a tree node to be used according to the memory boundary, until an initial tree node is determined, or until the memory boundary is the same size as the memory space corresponding to the root node of the partner tree, and the latest determined tree node to be used cannot be used as the initial tree node, and it is determined that there is no initial tree node.

[0034] In one possible implementation, the method further includes:

[0035] In response to the release of any object's memory space, based on the address and length of the object's memory space, the first target memory node to which the object's memory space belongs and the object to be released to which the object belongs in the first target memory node are determined, and the object metadata of the object to be released maintained by the first target memory node is modified.

[0036] In response to the release of memory space of any node, the second target memory node to which the node memory space belongs and the tree node to be released to which the second target memory node belongs are determined based on the address and length of the node memory space, and the node metadata of the tree node to be released is modified.

[0037] In one possible implementation, the method further includes:

[0038] In the event that the first client that initiated the memory access request crashes, the reachability of each allocated object and the object set maintained by the first client on the memory node are obtained; the object set includes each partitioned object with leakability; the leakability is used to indicate whether the partitioned object is likely to be leaked when the first client crashes; the reachability is used to indicate whether the memory space corresponding to the allocated object is reachable from the object graph;

[0039] Objects located in the object set that are not reachable are identified as memory leak objects and memory leak recovery is performed.

[0040] In one possible implementation, the object set is maintained according to the following steps:

[0041] For any partitioned object, if the partitioned object is being assigned to a second client that is initiating a memory access request, or if the partitioned object is not inserted into the object graph, it is determined that the partitioned object is leakable.

[0042] Determine the memory node to which the partitioned object belongs, and insert the partitioned object into the object set maintained for the second client on that memory node;

[0043] In response to the partitioned object being assigned to the second client and inserted into the object graph, the partitioned object is deleted from the object set maintained for the second client on that memory node.

[0044] In one possible implementation, the reachability is maintained according to the following steps:

[0045] For any allocated object, in response to the insertion of the allocated object into the object graph, the memory address corresponding to the parent node object of the allocated object is initialized to the reverse pointer of the allocated object;

[0046] Whether the allocated object is reachable is determined by whether a pointer loop is formed between the reverse pointer of the allocated object and the forward pointer of the parent node object; the forward pointer of the parent node object is used to indicate the memory address of the child node object pointed to by the parent node object.

[0047] Secondly, embodiments of this disclosure also provide a memory management device, including:

[0048] The determination module is used to determine each unallocated object after a memory access request is generated, based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated.

[0049] The selection module is configured to, if the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, select a target tree node from the tree nodes and modify the node metadata of the target tree node based on the node metadata of each tree node in each partner tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a partner tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a partner tree correspond to different memory spaces;

[0050] The partitioning module is used to divide the second memory space corresponding to the target tree node into multiple objects, and select each target object from the multiple objects that matches the size of the first memory space.

[0051] The allocation module is used to allocate the target object to the memory access request and maintain the object metadata of each object corresponding to the target tree node in the memory node.

[0052] Thirdly, an optional implementation of this disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the first aspect above, or any possible implementation of the first aspect.

[0053] Fourthly, an optional implementation of this disclosure also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps as described in the first aspect above, or any possible implementation of the first aspect.

[0054] The memory management method, apparatus, storage medium, and computer device provided in this disclosure support the partitioning of separate memory at the tree node and object granularity, and maintain the metadata of both tree nodes and partitioned objects on memory nodes. This allows independent and concurrent access to metadata by various application clients, and the allocation and release of memory corresponding to tree nodes and objects using metadata. This ensures that each partitioned object can be accessed by other clients immediately after release, solving the problem of memory bloat, avoiding unnecessary occupation of separate memory, and improving memory utilization efficiency. Furthermore, after generating a memory access request, by first partitioning the unallocated objects among the partitioned objects, and then selecting tree nodes for object partitioning and allocation when the unallocated objects cannot meet the required initial memory space, it is possible to achieve timely use of partitioned objects and reduce the allocation pressure brought by tree node selection and object partitioning by allocating partitioned objects, thus helping to improve memory management efficiency.

[0055] Furthermore, the memory management method, apparatus, storage medium, and computer device provided in this disclosure can also actively maintain the reachability of each allocated object and the set of objects that are leakable. This enables the rapid identification and recovery of partitioned objects at risk of leakage when the client crashes, reducing the complexity and overhead of memory recovery and improving the efficiency of memory recovery.

[0056] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0057] Figure 1 This is a schematic diagram illustrating a prior art two-level memory management strategy in an exemplary embodiment of this application;

[0058] Figure 2 This is a schematic diagram illustrating a prior art memory usage bloat problem, as shown in an exemplary embodiment of this application;

[0059] Figure 3 This is a flowchart illustrating a memory management method in an exemplary embodiment of this application;

[0060] Figure 4 This is a schematic diagram of a partner tree structure shown in an exemplary embodiment of this application;

[0061] Figure 5 This is a schematic diagram illustrating the concept of a memory management method according to an exemplary embodiment of this application;

[0062] Figure 6 This is a schematic diagram illustrating the architecture of a memory management method according to an exemplary embodiment of this application;

[0063] Figure 7 This is a schematic diagram illustrating a memory management device according to an exemplary embodiment of this application;

[0064] Figure 8 This is a schematic diagram of the structure of a computer device shown in an exemplary embodiment of this application. Detailed Implementation

[0065] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0066] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0067] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0068] Research has revealed that in the DM architecture, computing and memory resources within the cluster are divided into independent computing and memory pools. These resources can be independently allocated and flexibly expanded, significantly improving resource utilization within the cluster. The computing pool consists of computing nodes responsible for running application client processes, equipped with a high-performance Central Processing Unit (CPU) and a small amount of memory. The memory pool consists of memory nodes responsible for storing data accessed by decoupled memory applications, equipped with a large amount of memory and a CPU with relatively weak computing power. The memory pool exposes memory semantic access interfaces to the computing pool, including read, write, and compare-and-swap (CAS) interfaces. High-speed network interconnection between the computing pool and the memory pool is achieved through interconnection methods such as Remote Direct Memory Access (RDMA). RDMA supports both one-sided and two-sided communication mechanisms; the network primitives used for one-sided and two-sided communication are called two-sided network primitives and one-sided network primitives, respectively. Both types of network primitives have microsecond-level network round-trip latency. In a DM architecture, client processes running on compute nodes primarily access discrete memory located on memory nodes through one-sided network primitives. Memory management, as the fundamental means of memory usage between compute and memory nodes, enables memory allocation and deallocation. Existing memory management methods generally employ a two-level (TL) memory management strategy to achieve memory management and deallocation. For example... Figure 1 The diagram shown is a schematic representation of a prior art two-level memory management strategy provided in an embodiment of this application. Wherein, in Figure 1In the two-level memory management strategy illustrated, memory nodes and compute nodes are interconnected via an RDMA network. Memory nodes implement coarse-grained memory management, providing fixed-size memory blocks to compute nodes. Compute nodes, on the other hand, implement fine-grained memory management, dividing the memory blocks provided by memory nodes into objects using a SLAB allocation system, with memory allocation and deallocation at the object level. While existing two-level memory management strategies can achieve separate memory allocation and deallocation, they struggle to handle scenarios with a large number of mixed memory management and deallocation operations in real-world workloads. Under such workloads, as separate memory is repeatedly allocated and deallocated, the two-level strategy faces the problem of severe expansion of separate memory usage, and the amount of separate memory used does not decrease significantly even after it is released. This is because, in existing two-level memory management strategies, although application clients can release object memory, other objects within the memory blocks containing these released objects may still be occupied by the application clients. This prevents the memory blocks containing the released objects from being released back to the memory node or shared by other clients. These unshareable free memory blocks contribute to the expansion of memory usage. like Figure 2 The diagram shown illustrates a prior art method for addressing memory bloat issues, as provided in this application. Figure 2 In a DM architecture, after dividing the memory block provided by a memory node into multiple objects, these objects can be allocated to different application clients. When an application client finishes using the allocated objects, these objects can be released. However, because other objects in the memory block may be being used by other application clients, the released objects in that memory block, even though they become free memory, cannot be allocated and used, thus becoming frozen memory. More seriously, the scale of application clients in a DM architecture is often large, with the number expanding to hundreds or even thousands. The non-shareable free memory will expand proportionally with the expansion of application clients, further amplifying the problem of memory consumption inflation.

[0069] Memory management algorithms also need to handle memory leaks caused by application client crashes. That is, if the client crashes during memory management, objects being allocated may be leaked, thus requiring recovery of potentially leaky objects. Current memory leak recovery methods use garbage collection (GC), which traverses the object graph to determine object reachability and treats unreachable objects as memory leaks, recovering them. However, because garbage collection requires scanning the object graph located in separate memory, this process introduces a large number of pointer chasing operations. This consumes the limited access bandwidth of separate memory and causes high memory recovery latency, making the existing garbage collection-based memory leak recovery technology too expensive.

[0070] Therefore, how to solve the serious problem of fragmented memory bloat when managing fragmented memory under real-world workloads, reduce memory recovery latency when memory leaks occur, and avoid the overhead of memory recovery processes has become a technical issue worthy of attention.

[0071] Based on the above research, this disclosure provides a memory management method, apparatus, storage medium, and computer device. By supporting the partitioning of separate memory at the tree node and object granularity, and maintaining the metadata of both tree nodes and partitioned objects on memory nodes, it enables independent and concurrent access to metadata by various application clients. The metadata is used to allocate and release memory corresponding to tree nodes and objects, ensuring that each partitioned object can be accessed by other clients immediately after release. This solves the problem of memory bloat, avoids unnecessary occupation of separate memory, and improves memory utilization efficiency. Furthermore, after generating a memory access request, by first partitioning the unallocated objects among the partitioned objects, and then selecting tree nodes for object partitioning and allocation when the unallocated objects cannot meet the required initial memory space, it not only enables timely use of partitioned objects but also reduces the allocation pressure brought by tree node selection and object partitioning by allocating partitioned objects, thus contributing to improved memory management efficiency. Furthermore, by actively maintaining the reachability of each allocated object and the set of objects that are leakable, it is possible to quickly identify and recover the allocated objects at risk of leakage when the client crashes, reducing the complexity and overhead of memory recovery and improving the efficiency of memory recovery.

[0072] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below are all contributions made by the inventor to this disclosure.

[0073] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0074] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0075] To facilitate understanding of this embodiment, a memory management method disclosed in this disclosure will first be described in detail. The execution subject of the memory management method provided in this disclosure is generally a terminal device or other processing device with certain computing capabilities. The terminal device can be a user equipment (UE), a mobile device, a terminal, a personal digital assistant (PDA), a handheld device, a computer device, or a computing node where an application client running on a computing node is located. In some possible implementations, the memory management method can be implemented by the processor calling computer-readable instructions stored in the memory.

[0076] The memory management method provided in this disclosure embodiment will be described below using the execution subject as a computing node as an example.

[0077] like Figure 3 The flowchart shown is a memory management method provided in an embodiment of this disclosure, which may include the following steps:

[0078] S301: After generating a memory access request, determine each unallocated object based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated.

[0079] Here, a memory access request can be initiated by any application client running on any compute node. This request is used to access decoupled memory on a memory node within the memory pool. The memory node to be accessed by any memory access request can be specified by the application client initiating the memory access request.

[0080] The management and access of split memory needs to be adapted to the DM architecture. Considering the relatively weak computing power of memory nodes in the DM architecture, the split memory management algorithm should not be executed by the memory nodes, but by the compute nodes. Therefore, the memory management method provided in this application adopts a scheme in which all execution is performed by the compute nodes to achieve an efficient memory management mechanism for split memory and solve the problem of memory bloat in existing memory management technologies. Specifically, the executing entity in this application can be the compute node where the application client that initiates the memory access request is located.

[0081] The partitioned objects are the objects that have been allocated from the memory provided by memory nodes to other application clients (this memory can be a memory page or a contiguous page, as described later). These objects can be SLAB objects allocated through the SLAB allocation system. One partitioned object corresponds to one memory space, and different partitioned objects correspond to different memory spaces.

[0082] Unlike existing two-level memory management strategies, the memory management metadata in this application is stored at known locations on the memory nodes where the separate memory resides. By maintaining fine-grained memory management metadata at known locations on each memory node, this application allows different application clients on different computing nodes to directly, concurrently, and sharedly access the metadata, thereby achieving object-level memory allocation and release. Specifically, the memory management metadata can include metadata from the buddy system and metadata from the SLAB allocation system. The buddy system is a system that supports variable-length memory allocation, enabling the allocation and release of memory pages or contiguous pages (i.e., the memory space corresponding to tree nodes other than leaf nodes in the buddy tree, as described later), and serving the SLAB allocation system by providing it with pages or contiguous pages. The SLAB allocation system is a system that supports fast allocation of fixed-length objects, which can divide a page or contiguous page into a group of free objects called a SLAB, and serve the application client's object allocation and release requests. All SLAB objects within a SLAB are of the same size; SLAB objects of different sizes will reside in different SLABs.

[0083] The metadata of the buddy system can specifically include the node metadata of each tree node in each buddy tree (described later). Node metadata indicates the node allocation status of a tree node, specifically whether it has been allocated. The metadata of the SLAB allocation system can specifically include the object metadata of each partitioned object. Object metadata indicates the object allocation status of a partitioned object, specifically whether it has been allocated.

[0084] The SLAB allocation system uses bitmaps to implement slabs to manage the allocation status of objects; the allocation status uses one bit to indicate whether an object has been allocated or not. That is, the object metadata of a partitioned object can be represented using one bit of the bitmap containing that partitioned object.

[0085] Unallocated objects are SLAB objects that have not been allocated to any application client for use; in other words, they are idle SLAB objects.

[0086] In practice, after any application client generates a memory access request, the compute node where the application client resides can retrieve the object metadata of each partitioned object maintained by the memory node in the memory pool that the memory access request requires. Then, based on whether the partitioned objects have been allocated as indicated by the node metadata, the compute node determines the partitioned objects that have not been allocated, i.e., it determines the unallocated objects. For example, the compute node can obtain the bitmaps maintained by the memory nodes and determine the unallocated objects in the memory nodes based on the allocation status indicated by each bit in the bitmap.

[0087] Because this application selects tree nodes from the buddy tree first and then partitions and allocates the memory space corresponding to the tree nodes using SLAB objects during memory allocation, each allocated tree node can correspond to a bitmap. After the application client generates a memory access request, the compute node can determine the allocated tree nodes based on the node metadata of the tree nodes in each buddy tree within the memory node. Then, based on the bitmap corresponding to each allocated tree node, it determines the unallocated objects corresponding to each allocated tree node.

[0088] S302: If the contiguous memory space composed of all unallocated objects does not match the first memory space required by the memory access request, then select the target tree node from each tree node and modify the node metadata of the target tree node according to the node metadata of each tree node in each buddy tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a buddy tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a buddy tree correspond to different memory spaces.

[0089] Here, for each memory node, the number of companion trees corresponding to that memory node can be pre-determined based on the memory space size and the maximum preset space size. Then, companion trees are pre-created according to this number, and the memory space corresponding to the memory node is allocated to each companion tree for management. Each companion tree manages a portion of the contiguous memory space corresponding to the memory node. Different companion trees manage different contiguous memory spaces corresponding to the memory node. For example, with a maximum preset space size of 2GB and a memory node corresponding to 10GB of memory space, 5 companion trees can be created, each managing a contiguous 2GB space within the 10GB memory space. The combined contiguous space managed by the 5 companion trees constitutes the 10GB memory space. As another example, with a maximum preset space size of 2GB and a memory node corresponding to 11GB of memory space, 6 companion trees can be created. The first 5 companion trees manage a contiguous 2GB space within the 11GB memory space, and the 6th companion tree manages the remaining 1GB of space.

[0090] Each memory node corresponds to a buddy tree, and each node within a buddy tree is pre-defined. Different nodes within a buddy tree correspond to different memory spaces within the memory node. The node metadata for each node in each buddy tree can be pre-maintained in the memory node and can be directly retrieved by each compute node when needed. Specifically, the node metadata can be used to indicate whether a tree node has been allocated.

[0091] Specifically, the root node of a buddy tree corresponds to a memory space of a maximum preset size; sibling nodes in a tree node are obtained by uniformly dividing the memory space corresponding to the parent node; leaf nodes in a tree node are memory pages with a target size. The target size is a preset size, which can be set empirically and is not specifically limited in this embodiment. For example, the target size can be 4KB. The node metadata of each tree node in the buddy tree is stored in a contiguous array in the order of subsequent traversal of each tree node.

[0092] In practical implementation, logically, the buddy tree is a perfect binary tree. Its root node represents the entire memory space allocated to the tree (this memory space is at most the maximum preset size mentioned above). All tree nodes in the buddy tree, except for leaf nodes, divide their corresponding memory space in half and recursively assign each half to their two child nodes. Each leaf node has no child nodes; they represent a memory page, which is the smallest management unit in the buddy system. This application organizes the node metadata of the buddy tree, which has a logical structure of a binary tree, into a contiguous array for storage. The node metadata of each tree node is encoded with 1 bit to represent the node's allocation status, which includes two states: allocated (ALLOC) and unallocated (FREE). Application clients can initiate read operations on the contiguous array to read the node metadata of each tree node and initiate CAS operations to modify the node metadata of tree nodes. Tree nodes are stored in a contiguous array in the order of subsequent traversal of the sibling tree. The advantage of this storage order is that sibling tree nodes within the same subtree are stored close to each other in the contiguous array, thus allowing application clients to access multiple tree nodes within the same subtree with fewer separate memory access operations.

[0093] For example, in this application, the buddy system manages discrete memory at the granularity of memory pages (e.g., 4KB). The buddy system contains multiple buddy trees, each responsible for up to 2GB of memory space on a memory node. This memory space is divided into different pages and allocated to different tree nodes. Each leaf node corresponds to a partitioned memory page, and each tree node (excluding leaf nodes) corresponds to at least two consecutive pages. Therefore, the memory space corresponding to each tree node (excluding leaf nodes) can be called a contiguous page. The node metadata of each tree node in each buddy tree can be stored in a contiguous array corresponding to that buddy tree, with one bit in the array representing the node metadata of a tree node. The node metadata of all buddy trees supports shared access by different computing nodes. The memory space managed by any buddy tree must correspond to the memory space of the same memory node; there will be no situation where a buddy tree manages the memory space corresponding to different memory nodes.

[0094] The target tree node mentioned above is an unallocated tree node selected from among the tree nodes in the various buddy trees maintained by the memory node. For example... Figure 4 The diagram shown is a schematic representation of a partner tree structure provided in an embodiment of this application. Figure 4 In the context of the buddy tree, the root node 0 corresponds to 8 memory pages (i.e., ...). Figure 4 The memory space is divided into 8 pages (root node 0, 8 pages). Under the root node are two child nodes (tree nodes 1 and 2), each corresponding to 4 pages. Under tree node 1 are two child nodes (tree nodes 3 and 4), each corresponding to 2 pages. Under tree node 2 are two child nodes (tree nodes 5 and 6), each corresponding to 2 pages. Under tree node 3 are two child nodes (tree nodes 7 and 8), each corresponding to 1 page. Under tree node 4 are two child nodes (tree nodes 9 and 10), each corresponding to 1 page. Similarly, tree node 5 includes tree nodes 11 and 12, each corresponding to a page, and tree node 6 includes tree nodes 13 and 14, each corresponding to a page. Figure 4 In the process, tree node 4 is identified as the target tree node corresponding to a certain memory access request. The target tree node is a consecutive page with a length of 2 pages.

[0095] The first memory space can be the size of the memory space requested by the memory access request.

[0096] In practice, each partner tree can be traversed sequentially based on its index. For the currently traversed partner tree, the allocated tree nodes matching the first memory space size are determined based on the memory space size of each tree node and its metadata. The allocated tree nodes are then traversed in ascending order of different levels and from left to right (or from right to left) within the same level. For each currently traversed allocated tree node, the corresponding unallocated objects are determined based on its bitmap. Then, it is determined whether the memory spaces corresponding to these unallocated objects can form a contiguous target memory space that satisfies the first memory space requirement. If so, the target contiguous memory space is considered a match for the first memory space, and the unallocated objects are allocated to the application client that initiated the memory access request. If not, the process continues traversing the next allocated tree node until all unallocated objects that can form the target contiguous memory space are identified, or until all allocated tree nodes in the buddy tree have been traversed, then the process continues traversing the next buddy tree. If, after traversing all allocated tree nodes in each buddy tree, a target contiguous memory space that can satisfy the first memory space is still not identified, then it can be determined that the contiguous memory spaces formed by the unallocated objects do not match the first memory space.

[0097] Optionally, during step S301, the allocated tree nodes in each partner tree can be determined first, and then the unallocated objects corresponding to each allocated tree node can be determined based on the bitmap corresponding to each allocated tree node. Then, during step S302, the unallocated objects corresponding to each allocated tree node can be judged in any order to determine whether they can form a target contiguous memory space that satisfies the first memory space requirement. If so, the unallocated objects corresponding to the target contiguous memory space can be directly allocated to the application client corresponding to the memory access request. If not, the judgment can continue for the unallocated objects corresponding to the next allocated tree node until it is determined that the unallocated objects corresponding to a certain tree node can form a target contiguous memory space that satisfies the first memory space requirement, and then the unallocated objects corresponding to the target contiguous memory space are allocated to the application client corresponding to the memory access request; or, until all allocated tree nodes have been judged and it is determined that the contiguous memory space formed by the unallocated objects does not match the first memory space required by the memory access request.

[0098] Furthermore, if the contiguous memory space comprised of all unallocated objects does not match the first memory space required by the memory access request, it can be determined that the unallocated objects cannot provide a contiguous memory space to satisfy the memory access request. Therefore, based on the node metadata of each tree node in each buddy tree maintained by each memory node, a target tree node that can satisfy the first memory space and is unallocated can be selected from each buddy tree. The node metadata can be obtained synchronously when acquiring the object metadata.

[0099] Specifically, when selecting a target tree node, the compute node can always start attempting allocation from the same buddy tree to reduce memory fragmentation. If the current buddy tree cannot satisfy the allocation request, a new buddy tree will be selected and the process will be retried. For example, the selection order of each buddy tree can be determined first, and the buddy trees can be selected sequentially according to this order. For each selected buddy tree, the unallocated tree nodes can be determined based on the node metadata of each tree node in the buddy tree. If there is a tree node among the unallocated tree nodes that satisfies the memory access request, that tree node will be used as the target tree node; if there is no tree node among the unallocated tree nodes that satisfies the memory access request, the next buddy tree can be selected until the target tree node that satisfies the memory access request is determined. The selection order can be a preset order or determined based on the number of tree nodes allocated in each buddy tree.

[0100] Once the target tree node is identified, its state can be modified to indicate that it has been assigned.

[0101] In one embodiment, the step of selecting the target tree node in S302 above can be implemented according to the following steps:

[0102] S302-1: Traverse each partner tree. For the currently traversed partner tree, determine the corresponding target level in the partner tree based on the first memory space.

[0103] Here, the traversal order can be predetermined after the buddy trees on the memory nodes are partitioned, or each buddy tree can be assigned an index, with the indexes of the buddy trees maintained by the same memory node being sequentially incremented. The traversal order of the buddy trees is then determined based on the index. A buddy tree can include multiple levels, and each level can include at least one tree node. The lowest level is the level where all leaf nodes are located, and the highest level is the level where the root node is located. The target level is the level selected from the multiple levels corresponding to the currently traversed buddy tree.

[0104] In practice, the buddy trees maintained by each memory node can be traversed in traversal order. For the currently traversed buddy tree, the number of pages corresponding to the first memory space required by the memory access request is determined. Based on the number of pages and the number of pages corresponding to each level in the currently traversed buddy tree, the target level is determined from the various levels corresponding to the buddy tree. The number of pages corresponding to a certain level is the number of pages included in the memory space corresponding to any tree node under that level. For example, in... Figure 4 In this system, the highest level (i.e., the first level) has 8 pages, and the lowest level has 1 page.

[0105] In one embodiment, S302-1 described above can be implemented according to the following steps:

[0106] S302-1-1: Determine the object partitioning dimensions.

[0107] Here, the object partition size is the SLAB size, which indicates the number of objects when performing SLAB object partitioning on the second memory space. For example, the object partition size can be 3×3, 5×5, 10×10, etc.

[0108] All SLAB objects within a SLAB are the same size, and the number of SLAB objects is the number indicated by the SLAB size.

[0109] In practice, to improve slab utilization and reduce additional overhead on split memory, the usage frequency of various SLAB sizes can be obtained to dynamically determine the object partitioning size required when dividing SLAB objects. For example, frequently used SLAB sizes can be used as object partitioning sizes. The usage frequency of a SLAB size can be determined based on the allocation frequency of objects within that size. Thus, by dynamically determining the object partitioning size, the SLAB sizes corresponding to frequently allocated objects can be utilized more extensively, thereby reserving more SLAB objects that are likely to be frequently allocated and reducing the overhead on split memory.

[0110] S302-1-2: Determine the third memory space based on the object partition size, the reserved space for each object, and the first memory space.

[0111] The size of the reserved space can be set based on experience, and this embodiment does not impose a specific limitation. For example, the reserved space can be 8 bytes. The reserved space can be used to store the reverse pointer mentioned later.

[0112] The third memory space is the minimum memory space required to allocate memory for this memory access request.

[0113] In practice, the total amount of additional space required can be determined based on the object's partition size and the reserved space for each object. Then, the third memory space can be determined based on this total space and the first memory space. For example, the target sum of the total space and the first memory space can be used as the third memory space. Alternatively, the smallest multiple greater than the target sum can be selected from multiples of the target space size as the third memory space.

[0114] S302-1-3: Determine the corresponding target level in the buddy tree based on the size of the third memory space and the target space.

[0115] In practice, if the third memory space is equal to the target size mentioned above, the third memory space can be divided by the target space size and rounded up. The resulting value is used as the number of pages to be selected. Then, based on this number of pages and the number of pages corresponding to each level in the currently traversed buddy tree, the target level is determined.

[0116] S302-2: Based on the node metadata of each candidate tree node located in the target level, determine from the partner tree whether there is an initial tree node that can be assigned.

[0117] Here, candidate tree nodes are tree nodes located at the target level of the currently traversed partner tree. For example, in Figure 4 In the process, if the target level is the second level, the candidate tree nodes are tree nodes 1 and 2; if the target level is the third level, the candidate tree nodes are tree nodes 3, 4, 5, and 6. The initial tree nodes are unassigned tree nodes indicated by node metadata.

[0118] In practice, the existence of unassigned candidate tree nodes in the partner tree can be determined based on the node metadata of each candidate tree node. If so, any tree node among the unassigned candidate tree nodes can be used as the initial tree node that can be assigned, and S302-3 below can be executed. If not, it can be determined to continue traversing the next partner tree.

[0119] In one embodiment, the above-described S302-2 can be implemented according to the following steps:

[0120] S302-2-1: Determine the memory boundary based on the memory space size corresponding to any randomly selected candidate tree node, and select the tree node to be used according to the memory boundary; the memory boundary is used to indicate the tree nodes that can be selected.

[0121] Here, this application employs a randomized method to select tree nodes, thereby preventing concurrent application clients from selecting the same tree node and introducing concurrency conflicts. Furthermore, the randomization is accompanied by a bounded range, thus avoiding the memory fragmentation problem introduced by unrestricted randomization within the buddy system. This bounded range can be called a memory boundary, indicating both the currently selectable memory space address and the currently available tree nodes.

[0122] In practice, for the currently traversed partner tree, after determining the target level, each tree node under the target level can be considered as a candidate tree node. Then, any candidate tree node is randomly selected, and the memory boundary is determined based on the candidate tree node and its corresponding memory address. At this point, the memory boundary includes only one candidate tree node.

[0123] Then, based on the current memory boundary, the candidate tree node located at that memory boundary can be selected from the candidate tree nodes included in the target level as the tree node to be used.

[0124] S302-2-2: If, based on the node metadata of the tree node to be used, it is determined that the tree node to be used cannot be used as the initial tree node, then the number of times the tree node to be used has been selected is determined.

[0125] Here, the situations where a tree node to be used cannot be the initial tree node can include at least one of the following: the node metadata of the tree node to be used indicates that the tree node to be used has been allocated; the node metadata of the tree node to be used indicates that the tree node to be used has not been allocated but the node metadata modification failed; the node metadata of the tree node to be used was successfully modified but at least one conflicting node has been allocated. The number of times a tree node to be used has been selected is the number of times a tree node to be used has been consecutively selected from the currently traversed buddy tree within the current memory boundary.

[0126] For example, if it is determined from the node metadata of the tree node to be used that the tree node to be used has already been assigned, then it can be determined that the tree node to be used cannot be used as the initial tree node. The number of times the tree node to be used has been selected can then be determined.

[0127] S302-2-3: If the number of attempts reaches the target number, the memory boundary is expanded by a preset multiple to obtain a new memory boundary; the target number of attempts is determined based on the number of tree nodes indicated by the memory boundary.

[0128] Here, the target number of iterations can be determined based on the number of tree nodes included in the current memory boundary.

[0129] Specifically, the target number of repetitions can be determined using the following formula:

[0130] N = log2(W); (Formula 1)

[0131] Where N represents the target number of times, and W represents the number of tree nodes included in the current memory boundary.

[0132] The preset multiplier can be set empirically, and this application embodiment does not impose specific limitations. For example, the preset multiplier can be determined based on the base of the logarithm in Formula 1 above, that is, when the base is 2, the preset multiplier can be 2. Specifically, for the first determined memory boundary, since this memory boundary only includes one candidate node, the target number of iterations corresponding to this memory boundary can be the value of Formula 1 above plus 1. For any memory boundary determined other than the first time, Formula 1 above can be directly used to determine the target number of iterations.

[0133] Expanding the memory boundary can be done by determining the number of tree nodes required for the new memory boundary based on a preset multiple and the number of tree nodes included in the current memory boundary. For example, if the current memory boundary has 1 tree node, after the first expansion, the number of tree nodes becomes 2; after the second expansion, it becomes 4; and after the third expansion, it becomes 8. Based on the required number of tree nodes for the new memory boundary and the candidate tree nodes at the target level, that number of candidate tree nodes are selected. The memory space address corresponding to the newly selected tree nodes is then determined based on the memory space address of the new memory boundary. The candidate tree nodes in the new memory boundary include those from the previously determined memory boundary.

[0134] In practice, if the number of times the tree node to be used has been selected has not reached the target number related to the memory boundary, new tree nodes to be used can be selected according to the current memory boundary, and the process returns to step S302-2-2 until a tree node that can be used as the initial tree node is determined. Alternatively, if the number of times the tree node to be used has been selected has reached the target number related to the memory boundary, the current memory boundary can be expanded according to a preset multiple to obtain a new memory boundary. Or, if the compute node or application client determines that the current memory limit cannot satisfy the memory access request, the memory boundary can also be expanded according to a preset multiple to obtain a new memory boundary.

[0135] S302-2-4: Return to the step of selecting the tree node to be used according to the memory boundary until the initial tree node is determined, or until the memory boundary is the same size as the memory space corresponding to the root node of the partner tree, and the latest determined tree node to be used cannot be used as the initial tree node, and it is determined that there is no initial tree node.

[0136] In practice, after determining the new memory boundary, we can return to the step "selecting tree nodes to be used according to memory boundaries" in S302-2-1 until a tree node that can be used as the initial tree node is determined, or until the latest memory boundary is consistent with the memory space size corresponding to the root node of the currently traversed partner tree, and the latest determined tree node to be used cannot be used as the initial tree node. In this case, we can determine that there is no initial tree node in the currently traversed partner tree, and continue to traverse the next partner tree to retry.

[0137] In other words, this application maintains a memory boundary for each application client, randomly selecting consecutive pages within the memory boundary to attempt allocation, and choosing the tree node corresponding to these consecutive pages as the target tree node. Initially, this memory boundary is small, containing only one candidate tree node. If the client fails to allocate successfully after N consecutive attempts, or if the application client determines that the memory access request cannot be satisfied within the memory boundary, the size of the memory boundary will be increased exponentially by a factor of 2, and allocation will be retried. This process will continue until the memory boundary covers the memory space corresponding to the root node of the entire buddy tree. If memory allocation fails again at this point, it indicates that the currently traversed buddy tree cannot satisfy the memory access request, and another buddy tree will be selected and retried.

[0138] by Figure 4 Taking the currently traversed buddy tree as an example, assuming the target level is the third level, during initial allocation, tree node 6 can be selected as the tree node in the memory boundary. Tree node 6 is then used as the node to be used. If tree node 6 cannot be used as the initial tree node, the consecutive count of selected nodes to be used is determined to be 1. Based on the current memory boundary, the target count is determined to be 1. Therefore, the memory boundary can be expanded to include tree nodes 5 and 6. Then, tree node 5 is selected as the node to be used. If tree node 5 cannot be used as the initial tree node, the consecutive count of selected nodes to be used is determined to be 1. Based on the current memory boundary, the target count is determined to be 1. Therefore, the memory boundary can be expanded to include tree nodes 3, 4, 5, and 6. Next, tree node 4 can be selected as the tree node to be used. If tree node 4 cannot be used as the initial tree node, it can be determined that the number of consecutive times the tree node to be used has been selected is 1. According to the current memory limit, the target number can be determined to be 2. Therefore, tree node 3 can be selected as the tree node to be used according to the current memory limit. If tree node 3 cannot be used as the initial tree node, it can be determined that the number of consecutive times the tree node to be used has been selected is 2. Since the memory boundary has already covered the memory space corresponding to the root node, the next buddy tree can be selected and retried.

[0139] S302-3: Based on the modification results of the node metadata of the initial tree node, determine whether to use the initial tree node as the target tree node.

[0140] In practice, after determining the initial tree node, a CAS operation can be used to attempt to change the target tree node's metadata from a state indicating the node is not assigned to a state indicating the node has been assigned. Then, based on the modification result, it can be determined whether to use the initial tree node as the target tree node.

[0141] In one embodiment, S302-3 described above can be implemented according to the following steps:

[0142] If the modification result indicates successful, then the ancestor and descendant tree nodes of the initial tree node in the partner tree are obtained. If the node metadata of all ancestor and descendant tree nodes indicates that they are unallocated, the initial tree node is used as the target tree node. The ancestor and descendant tree nodes of the initial tree node can also be referred to as conflicting nodes of the initial tree node. Conflicting tree nodes can have concurrent memory allocation conflicts with the initial tree node. Typically, because the memory space corresponding to the initial tree node overlaps with the memory space corresponding to conflicting nodes, if the initial tree node is allocated to an application client, then its conflicting nodes must not be currently used by other application clients. Otherwise, overlapping memory will be allocated to multiple application clients simultaneously, leading to memory usage conflicts. Therefore, after the initial tree node is successfully modified, to avoid concurrent allocation conflicts, the allocation status of conflicting nodes needs to be checked.

[0143] In another embodiment, if the node metadata of each ancestor tree node and each descendant tree node contains node metadata indicating that it has been allocated, then it is determined that the initial tree node cannot be used as the target tree node, and the modification of the node metadata of the initial tree node is cancelled; or, if the modification result indicates that the modification failed, then it is determined that the initial tree node cannot be used as the target tree node.

[0144] Here, if the modification result indicates that the modification failed, it can be determined that there is a conflicting concurrent memory allocation in the memory space corresponding to the initial tree node. That is, it can be determined that the memory space corresponding to the initial tree node has been allocated to multiple application clients at the same time. At this time, it can be determined that the initial tree node cannot be used as the target tree node.

[0145] If the modification result indicates success, but the memory space corresponding to the initial tree node may still have concurrent memory allocation conflicts caused by conflicting nodes, it is necessary to check the allocation status of conflicting nodes to avoid concurrent memory allocation problems caused by conflicting nodes. If the modification result indicates success, and the node metadata of each conflicting node indicates unallocated, it can be determined that there is currently no concurrent memory allocation conflict. Therefore, the initial tree node can be directly used as the target tree node, and the traversal of the partner tree can be stopped. If the modification result indicates success, but the node metadata of at least one conflicting node indicates allocated, it can be determined that there is currently any concurrent memory allocation conflict. The node metadata of the initial tree node can be modified back to indicate an unallocated status through a CAS operation, thereby canceling the modification of the node metadata of the initial tree node.

[0146] by Figure 4 For example, if the initial tree node is tree node 4, its ancestor tree nodes include tree node 1 and tree node 0, and its descendant tree nodes include tree node 9 and tree node 10. After successfully modifying the allocation status of tree node 4, if the allocation status of tree node 1, tree node 0, tree node 9, and tree node 10 are all unallocated, then there is no conflicting concurrent allocation problem, and tree node 4 can be used as the target tree node. If at least one of tree node 1, tree node 0, tree node 9, and tree node 10 has an allocated status, then there is a conflicting concurrent allocation problem, and the initial tree node cannot be used as the target tree node. The allocation status of tree node 4 should be modified back to indicate unallocated.

[0147] Optionally, if the modification result indicates that the modification failed, or if there is node metadata indicating that the node has been assigned in the node metadata of each ancestor tree node and each descendant tree node, if there are other candidate tree nodes in the currently traversed partner tree, the candidate tree node can continue to be used as the initial tree node. Based on the modification result of the node metadata of the initial tree node, it is determined whether to use the initial tree node as the target tree node, until the target tree node is determined from the currently traversed partner tree, or until it is determined that there is no candidate tree node that can be used as the target tree node in the currently traversed partner tree, then the next partner tree can be traversed until the target tree node is selected.

[0148] In another embodiment, if the initial tree node does not exist in the currently traversed partner tree, or if it is determined that the initial tree node cannot be used as the target tree node, then the next partner tree is traversed until the target tree node is determined.

[0149] In practice, if there is no initial tree node that can be assigned in the currently traversed partner tree, or if none of the initial tree nodes that can be assigned in the currently traversed partner tree can be used as the target tree node, then the step of traversing each partner tree can be returned to continue traversing the next partner tree in the traversal order until the target tree node is determined from any partner tree.

[0150] by Figure 4 For example, if the target level is the third level, and all tree nodes 3 to 6 in the third level are assigned tree nodes, or if there are unassigned tree nodes in tree nodes 3 to 6 but none of these unassigned tree nodes can be used as the target tree node, then it can be determined that... Figure 4 If the buddy tree shown cannot provide the target tree node, then you can return to the steps of traversing each buddy tree until the target tree node is determined.

[0151] S303: Divide the second memory space corresponding to the target tree node into multiple objects, and select each target object from the multiple objects that matches the size of the first memory space.

[0152] Here, the second memory space is the size of the memory space corresponding to the target tree node, and also the size of the contiguous pages corresponding to the target tree node. The second memory space corresponding to the target tree node is usually greater than or equal to the first memory space required by the memory access request.

[0153] In practice, the SLAB allocation system can be used to evenly divide the second memory space into multiple objects, and create bitmaps corresponding to these objects. Each bit in the bitmap represents the object metadata of each object, and initially, each bit in the bitmap indicates that the corresponding object has not been allocated. Then, from the memory spaces corresponding to the multiple objects, a target contiguous memory space that meets the size of the first memory space can be selected, and the objects corresponding to this target contiguous memory space can be used as the matching target objects.

[0154] S304: Assign the target object to the memory access request and maintain the object metadata of each object corresponding to the target tree node in the memory node.

[0155] In practice, each identified target object can be assigned to the application client initiating the memory access request to ensure that the application client can allocate the memory space corresponding to the target object to the memory access request. Simultaneously, CAS operations can be used to modify the object metadata corresponding to the bit in the bitmap of the target object to indicate that the object has been allocated.

[0156] In another embodiment, this application also supports object-level memory release. Specifically, in response to the release of any object memory space, the first target memory node to which the object memory space belongs and the object to be released to which the first target memory node belongs are determined based on the address and length of the object memory space, and the object metadata of the object to be released maintained by the first target memory node is modified.

[0157] Here, the object memory space can be the memory space corresponding to any partitioned object. The first target memory node is the memory node where the partitioned object corresponding to the object memory space to be released resides. The object to be released is the partitioned object corresponding to the object memory space to be released.

[0158] In practice, in response to the release of at least one object's memory space, for each released object's memory space, the first target memory node to which the object's memory space belongs is determined based on the object's memory space address and length, as well as the address of the corresponding memory space in each memory node. Then, based on the length and address of the memory spaces corresponding to each partitioned object in the first target memory node, the object to be released corresponding to that object's memory space is determined. Then, the object metadata of the object to be released, maintained by the first target memory node, can be modified using a CAS operation. For example, a single bit corresponding to the object to be released in the bitmap maintained by the first target memory node can be modified using a CAS operation.

[0159] In this way, unlike the two-level memory management strategy in the prior art, this application can significantly reduce the additional occupation of separate memory by modifying the object metadata of the SLAB object without introducing non-shareable free memory.

[0160] Furthermore, in response to the release of any node's memory space, the system can determine the second target memory node to which the node's memory space belongs and the tree node to be released to which the second target memory node belongs, based on the address and length of the node's memory space, and modify the node metadata of the tree node to be released.

[0161] Here, the node memory space can be the memory space corresponding to any allocated tree node. The second target memory node is the memory node containing the allocated tree node corresponding to the node memory space to be released. The tree node to be released is the allocated tree node corresponding to the node memory space to be released.

[0162] In practical implementation, in response to the release of contiguous pages of any size, the second target memory node to which the contiguous pages belong is calculated in reverse, based on the address and length of the memory space corresponding to the node of the contiguous pages, and the address of the memory space corresponding to each memory node. Then, based on the address and length of the memory space corresponding to each tree node in the second target memory node, the tree node to be released corresponding to the contiguous pages is determined. Then, the node metadata of the tree node to be released maintained by the second target memory node can be modified using CAS operations. For example, the position of the tree node to be released in the target contiguous array corresponding to each buddy tree maintained by the second target memory node can be modified using CAS operations. Here, the target contiguous array is the contiguous array containing the node metadata of the tree node to be released, and also the contiguous array corresponding to the buddy trees to which the tree node to be released belongs.

[0163] Alternatively, in response to the release of any memory page, the second target memory node to which the memory page belongs can be calculated in reverse, based on the address and length of the memory space corresponding to the memory page and the address of the corresponding memory space in each memory node. Then, based on the address and length of the memory space corresponding to each tree node in the second target memory node, the tree node to be released corresponding to the memory page can be determined. Then, the node metadata of the tree node to be released maintained by the second target memory node can be modified using a CAS operation. For example, the position of the tree node to be released in the target continuous array corresponding to each companion tree maintained by the second target memory node can be modified using a CAS operation. Here, the target continuous array is a continuous array containing the node metadata of the tree node to be released, and also a continuous array corresponding to the companion trees to which the tree node to be released belongs.

[0164] Understandably, when all the partitioned objects corresponding to any tree node in a memory node are in an unallocated state, it can be determined that the contiguous pages corresponding to that tree node have been released. At this time, it can be known that the memory space corresponding to that tree node can be released directly, for example, the node metadata of that tree node can be directly modified.

[0165] Once the contiguous pages corresponding to a tree node are released, the tree node can be allocated to other application clients. When allocating to other application clients, the SLAB objects in the memory space corresponding to the tree node are reallocated through the SLAB allocation system.

[0166] In one embodiment, since memory management also requires consideration of memory leak recovery, this application addresses the high technical overhead of garbage collection-based memory leak recovery in existing technologies by employing a series of data structures to proactively maintain the leakability and reachability of allocated memory during memory management, thereby eliminating the need to scan the object graph during memory leak recovery. The memory leak recovery process will be described in detail below:

[0167] In the event that the first client that initiated the memory access request crashes, obtain the reachability of each allocated object and the object set maintained by the first client in the memory node; the object set includes each partitioned object with leakability; leakability is used to indicate whether the partitioned object is likely to be leaked when the first client crashes; reachability is used to indicate whether the memory space corresponding to the allocated object is reachable from the object graph; objects located in the object set that are not reachable are identified as memory leak objects and memory leak recovery is performed.

[0168] Here, the first client is the client that initiates the memory access request. Allocated objects can be assigned to SLAB objects for each application client. For each application client, a collection of objects can be maintained on each memory node. This collection includes all the leakable partitioned objects corresponding to that application client. Leakability indicates whether a partitioned object is likely to be leaked if the first client crashes. Specifically, when a partitioned object is being allocated, or when a partitioned object has been allocated but not yet added to the object graph, that object has the potential to be leaked; therefore, that object is leakable.

[0169] Reachability refers to whether the memory space corresponding to an allocated partitioned object is reachable from the object graph. A partitioned object that is leakable and not reachable is an object that has experienced a memory leak and needs to be recovered in the event of a client crash.

[0170] In practical implementation, this application proactively maintains the leakability and reachability of partitioned objects during memory management, thereby avoiding the overhead of traversing the object graph like a garbage collection mechanism during memory leak recovery. For example, if the first client that initiated any memory access request crashes, the reachability of each allocated object can be obtained from the memory pool, and the object set of the first client maintained in each memory node can be obtained. Then, based on the reachability of each allocated object and the object set related to the first client maintained by each memory node, objects located in the object set that are not reachable are identified, and these objects are designated as memory leak objects at the time of the first client crash, and memory leak recovery operations are performed on these memory leak objects.

[0171] In one embodiment, for any application client, the object set of the application client on each memory node can be maintained according to the following steps 1 to 3:

[0172] Step 1: For any partitioned object, if the partitioned object is being assigned to a second client that is initiating a memory access request, or if the partitioned object is not inserted into the object graph, determine that the partitioned object is leakable.

[0173] Here, the second client can be any application client that initiates a memory access request.

[0174] In practice, for any partitioned object, if the partitioned object is being assigned to a second client that initiates any memory access request, or if the partitioned object has been assigned to a second client but has not yet been inserted into the object graph, then it can be determined that the partitioned object is leakable.

[0175] Step 2: Determine the memory node to which the partitioned object belongs, and insert the partitioned object into the object set maintained for the second client on that memory node.

[0176] In practice, for any partitioned object that may be leaky, the tree node to which the partitioned object belongs can be determined, and the memory node to which the tree node belongs can be used as the memory node to which the partitioned object belongs. Then, the set of objects maintained by the second client on that memory node can be determined, and the partitioned object that may be leaky can be inserted into that set of objects.

[0177] Step 3: In response to the fact that the partitioned object has been assigned to the second client and inserted into the object graph, delete the partitioned object from the object set maintained for the second client on the memory node.

[0178] In practice, for any partitioned object, if the partitioned object has been assigned to the second client and inserted into the object graph, it can be determined that the partitioned object no longer has leakability. Therefore, it can be determined that on the memory node to which the partitioned object belongs, there is an object set maintained for the second client, and the partitioned object is deleted from the object set.

[0179] For example, adding and removing partitioned objects from an object collection involves writing a log entry to the memory node containing the partitioned object. This log entry records the operation type (e.g., add, remove) and the object's address. To avoid excessive use of separate memory space on the memory node by log entries, the log entries can be truncated after every M log entries are written. M can be set empirically, and this embodiment does not impose a specific limitation. For example, M can be 1024. Specifically, the log entries are truncated by writing the memory addresses of all currently leakable partitioned objects corresponding to the second client to the separate memory on the memory node, and marking all previous log entries as invalid or deleted.

[0180] In one embodiment, the reachability of each allocated object can be maintained through the following steps A and B:

[0181] Step A: For any allocated object, in response to the object graph being inserted into the allocated object, initialize the memory address corresponding to the parent node object of the allocated object to the reverse pointer of the allocated object.

[0182] In practice, for any allocated object, in response to the insertion of the allocated object into the object graph, the application client that allocated the object initializes the allocated object. This initialization process involves determining the parent node object of the allocated object from among the various allocated objects included in the created objects, and initializing the memory address corresponding to the parent node object of the allocated object as a reverse pointer to the allocated object. The reverse pointer can be stored in reserved space at the beginning of the allocated object for executing the parent node object. For example, the memory address corresponding to the parent node object of the allocated object can be stored in the 8-byte memory area at the beginning of the allocated object and named the reverse pointer.

[0183] In this case, an allocated object can only be used by an application client after it has been initialized by the application client that uses the object.

[0184] Step B: Determine whether the allocated object is reachable based on whether the reverse pointer of the allocated object and the forward pointer of the parent node object form a pointer loop; the forward pointer of the parent node object is used to indicate the memory address of the child node object pointed to by the parent node object.

[0185] In practice, when querying the reachability of any allocated object, it can be determined whether a pointer cycle is formed between the reverse pointer of the allocated object and the forward pointer of its parent node in the object graph. If so, the allocated object is considered reachable; otherwise, it is considered unreachable. The creation method of the forward pointers for each allocated object in the object graph can refer to the existing methods for creating forward pointers in object graphs. The forward pointers are used to indicate the child node objects of the allocated object.

[0186] Understandably, if an allocated object is inserted into the object graph, but the application client using that allocated object hasn't initialized it, then the allocated object doesn't have a reverse pointer to its parent node, thus preventing the formation of a pointer cycle and rendering it unreachable. However, if an allocated object is inserted into the object graph, and the application client using that allocated object has already initialized it, then the allocated object will have a reverse pointer to its parent node, thus forming a pointer cycle and achieving reachability. The reachability of any allocated object from the object graph can be determined by checking for the existence of a pointer cycle, avoiding the high overhead of traversing the object graph.

[0187] As an exception, for the first allocated object corresponding to the root node of any tree node, the allocated object has no parent node object in the object graph, so the allocated object does not have a reverse pointer, but the allocated object is still reachable.

[0188] like Figure 5 The diagram shown illustrates the conceptual approach of a memory management method provided in this application. This application employs a fine-grained memory management strategy, maintaining fine-grained, shareably accessible memory management metadata on the memory nodes corresponding to the separate memory. This allows application clients running on the compute nodes to directly and concurrently access this metadata, enabling object-level memory allocation and release. The compute nodes and memory nodes can be interconnected via an RDMA network.

[0189] like Figure 6The diagram illustrates the architecture of a memory management method provided in this application. In the memory pool, the separate memory on memory nodes can be divided into multiple 2GB memory spaces. Each 2GB memory space is allocated to a buddy tree through a buddy system for management. For any target tree node, a contiguous page is allocated using a SLAB allocation system, which divides this contiguous page into multiple objects and manages the object metadata of each object using a bitmap. Then, the allocated objects from each object partitioned by the SLAB allocation system are inserted into the object graph. In the compute pool, compute nodes can run the application code of the separate application used by the application client, and then use the code library corresponding to the memory management method provided in this application to allocate the partitioned free objects to the application client.

[0190] Thus, the memory management system provided in this application consists of a buddy system for segregated memory and a SLAB allocation system. Fine-grained metadata related to memory management is stored in segregated memory, allowing application clients to directly and concurrently access this metadata. Application clients directly perform object-level memory allocation and deallocation on the segregated memory, significantly reducing the additional overhead on the segregated memory under real-world workloads and improving its utilization. Clients only use read operations and CAS operations to modify memory management-related metadata, enabling concurrent access and improving its performance. During memory management, the leakability and reachability of allocated objects are actively maintained to support a low-performance memory leak recovery process.

[0191] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0192] Based on the same inventive concept, this disclosure also provides a memory management device corresponding to the memory management method. Since the principle of the device in this disclosure for solving the problem is similar to the memory management method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0193] like Figure 7 The diagram shown is a schematic representation of a memory management device provided in an embodiment of this disclosure, comprising:

[0194] The determination module 701 is used to determine each unallocated object after generating a memory access request, based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated.

[0195] The selection module 702 is configured to, if the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, select a target tree node from the tree nodes and modify the node metadata of the target tree node based on the node metadata of each tree node in each partner tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a partner tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a partner tree correspond to different memory spaces;

[0196] The partitioning module 703 is used to divide the second memory space corresponding to the target tree node into multiple objects, and select each target object from the multiple objects that matches the size of the first memory space.

[0197] The allocation module 704 is used to allocate the target object to the memory access request and maintain the object metadata of each object corresponding to the target tree node in the memory node.

[0198] In one possible implementation, the root node of a sibling tree corresponds to a memory space of a maximum preset size; the sibling nodes in the tree node are obtained by uniformly dividing the memory space corresponding to the parent node; the leaf nodes in the tree node are memory pages with a target size.

[0199] The node metadata of each tree node in the partner tree is stored in a contiguous array in the order of subsequent traversal of each tree node.

[0200] In one possible implementation, the selection module 702, when selecting a target tree node from the tree nodes based on the node metadata of each tree node in each buddy tree maintained by the memory node and modifying the node metadata of the target tree node, is configured to:

[0201] Each of the partner trees is traversed, and for the currently traversed partner tree, the target level in the partner tree is determined according to the first memory space.

[0202] Based on the node metadata of each candidate tree node located in the target level, determine from the partner tree whether there is an initial tree node that can be assigned;

[0203] If so, based on the modification result of the node metadata of the initial tree node, determine whether to use the initial tree node as the target tree node.

[0204] In one possible implementation, the selection module 702, when determining whether to use the initial tree node as the target tree node based on the modification result of modifying the node metadata of the initial tree node, is configured to:

[0205] If the modification result indicates that the modification was successful, then obtain the ancestor tree nodes and descendant tree nodes of the initial tree node in the partner tree;

[0206] If the node metadata of each ancestor tree node and each descendant tree node indicates that it is not assigned, the initial tree node shall be used as the target tree node.

[0207] In one possible implementation, the selection module 702 is further configured to:

[0208] If the node metadata of each ancestor tree node and each descendant tree node contains node metadata indicating that it has been allocated, then it is determined that the initial tree node cannot be used as the target tree node, and the modification of the node metadata of the initial tree node is cancelled.

[0209] Alternatively, if the modification result indicates that the modification failed, it is determined that the initial tree node cannot be used as the target tree node.

[0210] In one possible implementation, the selection module 702 is further configured to:

[0211] If the initial tree node does not exist in the currently traversed partner tree, or if it is determined that the initial tree node cannot be used as the target tree node, then continue traversing the next partner tree until the target tree node is determined.

[0212] In one possible implementation, the selection module 702, when determining the target level corresponding to the buddy tree based on the first memory space, is configured to:

[0213] Determine the dimensions of the object;

[0214] The third memory space is determined based on the object partition size, the reserved space for each object, and the first memory space;

[0215] Based on the third memory space and the target space size, the corresponding target level in the buddy tree is determined.

[0216] In one possible implementation, the selection module 702, when determining from the partner tree whether there exists an initial tree node that can be allocated based on the node metadata of each candidate tree node located under the target level, is configured to:

[0217] The memory boundary is determined based on the memory space size corresponding to any randomly selected candidate tree node, and the tree node to be used is selected according to the memory boundary; the memory boundary is used to indicate the tree nodes that can be selected.

[0218] If, based on the node metadata of the tree node to be used, it is determined that the tree node to be used cannot be used as the initial tree node, then the number of times the tree node to be used has been selected is determined.

[0219] If the number of attempts reaches the target number, the memory boundary is expanded by a preset multiple to obtain a new memory boundary; the target number is determined based on the number of tree nodes indicated by the memory boundary.

[0220] Return to the step of selecting a tree node to be used according to the memory boundary, until an initial tree node is determined, or until the memory boundary is the same size as the memory space corresponding to the root node of the partner tree, and the latest determined tree node to be used cannot be used as the initial tree node, and it is determined that there is no initial tree node.

[0221] In one possible implementation, the allocation module 704 is further configured to:

[0222] In response to the release of any object's memory space, based on the address and length of the object's memory space, the first target memory node to which the object's memory space belongs and the object to be released to which the object belongs in the first target memory node are determined, and the object metadata of the object to be released maintained by the first target memory node is modified.

[0223] The selection module 702 is also used for:

[0224] In response to the release of memory space of any node, the second target memory node to which the node memory space belongs and the tree node to be released to which the second target memory node belongs are determined based on the address and length of the node memory space, and the node metadata of the tree node to be released is modified.

[0225] In one possible implementation, the device further includes a recovery module 705, for:

[0226] In the event that the first client that initiated the memory access request crashes, the reachability of each allocated object and the object set maintained by the first client on the memory node are obtained; the object set includes each partitioned object with leakability; the leakability is used to indicate whether the partitioned object is likely to be leaked when the first client crashes; the reachability is used to indicate whether the memory space corresponding to the allocated object is reachable from the object graph;

[0227] Objects located in the object set that are not reachable are identified as memory leak objects and memory leak recovery is performed.

[0228] In one possible implementation, the device further includes a first maintenance module 706 for maintaining the object set according to the following steps:

[0229] For any partitioned object, if the partitioned object is being assigned to a second client that is initiating a memory access request, or if the partitioned object is not inserted into the object graph, it is determined that the partitioned object is leakable.

[0230] Determine the memory node to which the partitioned object belongs, and insert the partitioned object into the object set maintained for the second client on that memory node;

[0231] In response to the partitioned object being assigned to the second client and inserted into the object graph, the partitioned object is deleted from the object set maintained for the second client on that memory node.

[0232] In one possible implementation, the device further includes a second maintenance module 707 for maintaining the accessibility according to the following steps:

[0233] For any allocated object, in response to the insertion of the allocated object into the object graph, the memory address corresponding to the parent node object of the allocated object is initialized to the reverse pointer of the allocated object;

[0234] Whether the allocated object is reachable is determined by whether a pointer loop is formed between the reverse pointer of the allocated object and the forward pointer of the parent node object; the forward pointer of the parent node object is used to indicate the memory address of the child node object pointed to by the parent node object.

[0235] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0236] Based on the same technical concept, embodiments of this application also provide a computer device. (Refer to...) Figure 8 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application, comprising:

[0237] The system includes a processor 801, a memory 802, and a bus 803. The memory 802 stores machine-readable instructions executable by the processor 801. The processor 801 executes these machine-readable instructions, and when executed, it performs the following steps: S301: After generating a memory access request, based on the object metadata maintained by the memory node to be accessed, it determines each unallocated object; the object metadata indicates whether the allocated objects have been allocated. S302: If the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, it then determines the unallocated objects based on the object metadata maintained by the memory node. The node metadata of each tree node in each partner tree is used to select a target tree node from the tree nodes and modify the node metadata of the target tree node; the node metadata is used to indicate whether the tree node is allocated; a partner tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a partner tree correspond to different memory spaces; S303: divide the second memory space corresponding to the target tree node into multiple objects, and select each target object that matches the size of the first memory space from the multiple objects; and S304: allocate the target object to the memory access request, and maintain the object metadata of each object corresponding to the target tree node in the memory node.

[0238] The aforementioned memory 802 includes a main memory 8021 and an external memory 8022. The main memory 8021, also known as internal memory, is used to temporarily store the computational data in the processor 801, as well as the data exchanged with external memory such as a hard disk 8022. The processor 801 exchanges data with the external memory 8022 through the main memory 8021. When the computer device is running, the processor 801 and the memory 802 communicate through the bus 803, so that the processor 801 executes the execution instructions mentioned in the above method embodiments.

[0239] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the memory management method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0240] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of the software update method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0241] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0242] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0243] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the device can also be implemented as dedicated logic circuitry.

[0244] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0245] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0246] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0247] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0248] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0249] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A memory management method, characterized in that, The method includes: After generating a memory access request, each unallocated object is determined based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated. If the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, then a target tree node is selected from the tree nodes and its node metadata is modified according to the node metadata of each tree node in each buddy tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a buddy tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a buddy tree correspond to different memory spaces; The second memory space corresponding to the target tree node is divided into multiple objects, and each target object that matches the size of the first memory space is selected from the multiple objects. The target object is allocated to the memory access request, and the object metadata of each object corresponding to the target tree node is maintained in the memory node.

2. The method according to claim 1, characterized in that, The root node of a sibling tree corresponds to a memory space of the maximum preset size; the sibling nodes in the tree node are obtained by uniformly dividing the memory space corresponding to the parent node; the leaf nodes in the tree node are memory pages with the target size. The node metadata of each tree node in the partner tree is stored in a contiguous array in the order of subsequent traversal of each tree node.

3. The method according to claim 1, characterized in that, The step of selecting a target tree node from among the tree nodes and modifying the node metadata of the target tree node based on the node metadata of each tree node in each buddy tree maintained by the memory node includes: Each of the partner trees is traversed, and for the currently traversed partner tree, the target level in the partner tree is determined according to the first memory space. Based on the node metadata of each candidate tree node located in the target level, determine from the partner tree whether there is an initial tree node that can be assigned; If so, based on the modification result of the node metadata of the initial tree node, determine whether to use the initial tree node as the target tree node.

4. The method according to claim 3, characterized in that, The step of determining whether to use the initial tree node as the target tree node based on the modification result of modifying the node metadata of the initial tree node includes: If the modification result indicates that the modification was successful, then obtain the ancestor tree nodes and descendant tree nodes of the initial tree node in the partner tree; If the node metadata of each ancestor tree node and each descendant tree node indicates that it is not assigned, the initial tree node is taken as the target tree node.

5. The method according to claim 4, characterized in that, The method further includes: If the node metadata of each ancestor tree node and each descendant tree node contains node metadata indicating that it has been allocated, then it is determined that the initial tree node cannot be used as the target tree node, and the modification of the node metadata of the initial tree node is cancelled. Alternatively, if the modification result indicates that the modification failed, it is determined that the initial tree node cannot be used as the target tree node.

6. The method according to claim 3, characterized in that, The method further includes: If the initial tree node does not exist in the currently traversed partner tree, or if it is determined that the initial tree node cannot be used as the target tree node, then continue traversing the next partner tree until the target tree node is determined.

7. The method according to claim 3, characterized in that, The step of determining the target level in the buddy tree based on the first memory space includes: Determine the dimensions of the object; The third memory space is determined based on the object partition size, the reserved space for each object, and the first memory space; Based on the third memory space and the target space size, the corresponding target level in the buddy tree is determined.

8. The method according to claim 3, characterized in that, The step of determining whether there exists an initial tree node that can be allocated from the partner tree based on the node metadata of each candidate tree node located at the target level includes: The memory boundary is determined based on the memory space size corresponding to any randomly selected candidate tree node, and the tree node to be used is selected according to the memory boundary; the memory boundary is used to indicate the tree nodes that can be selected. If, based on the node metadata of the tree node to be used, it is determined that the tree node to be used cannot be used as the initial tree node, then the number of times the tree node to be used has been selected is determined. If the number of attempts reaches the target number, the memory boundary is expanded by a preset multiple to obtain a new memory boundary; the target number is determined based on the number of tree nodes indicated by the memory boundary. Return to the step of selecting a tree node to be used according to the memory boundary, until an initial tree node is determined, or until the memory boundary is the same size as the memory space corresponding to the root node of the partner tree, and the latest determined tree node to be used cannot be used as the initial tree node, and it is determined that there is no initial tree node.

9. The method according to claim 1, characterized in that, The method further includes: In response to the release of any object's memory space, based on the address and length of the object's memory space, the first target memory node to which the object's memory space belongs and the object to be released to which the object belongs in the first target memory node are determined, and the object metadata of the object to be released maintained by the first target memory node is modified. In response to the release of memory space of any node, the second target memory node to which the node memory space belongs and the tree node to be released to which the second target memory node belongs are determined based on the address and length of the node memory space, and the node metadata of the tree node to be released is modified.

10. The method according to claim 1, characterized in that, The method further includes: In the event that the first client that initiated the memory access request crashes, the reachability of each allocated object and the object set maintained by the first client on the memory node are obtained; the object set includes each partitioned object with leakability; the leakability is used to indicate whether the partitioned object is likely to be leaked when the first client crashes; the reachability is used to indicate whether the memory space corresponding to the allocated object is reachable from the object graph; Objects located in the object set that are not reachable are identified as memory leak objects and memory leak recovery is performed.

11. The method according to claim 10, characterized in that, The collection of objects is maintained according to the following steps: For any partitioned object, if the partitioned object is being assigned to a second client that is initiating a memory access request, or if the partitioned object is not inserted into the object graph, it is determined that the partitioned object is leakable. Determine the memory node to which the partitioned object belongs, and insert the partitioned object into the object set maintained for the second client on that memory node; In response to the partitioned object being assigned to the second client and inserted into the object graph, the partitioned object is deleted from the object set maintained for the second client on that memory node.

12. The method according to claim 10, characterized in that, The reachability is maintained according to the following steps: For any allocated object, in response to the insertion of the allocated object into the object graph, the memory address corresponding to the parent node object of the allocated object is initialized to the reverse pointer of the allocated object; Whether the allocated object is reachable is determined by whether the reverse pointer of the allocated object and the forward pointer of the parent node object of the allocated object form a pointer ring; The forward pointer of the parent node object is used to indicate the memory address of the child node object that the parent node object points to.

13. A memory management device, characterized in that, The device includes: The determination module is used to determine each unallocated object after a memory access request is generated, based on the object metadata of each partitioned object maintained by the memory node to be accessed by the memory access request; the object metadata is used to indicate whether the partitioned object has been allocated. The selection module is configured to, if the contiguous memory space composed of the unallocated objects does not match the first memory space required by the memory access request, select a target tree node from the tree nodes and modify the node metadata of the target tree node based on the node metadata of each tree node in each partner tree maintained by the memory node; the node metadata is used to indicate whether the tree node has been allocated; a partner tree is used to manage the memory of the maximum preset space size in the memory node; different tree nodes in a partner tree correspond to different memory spaces; The partitioning module is used to divide the second memory space corresponding to the target tree node into multiple objects, and select each target object from the multiple objects that matches the size of the first memory space. The allocation module is used to allocate the target object to the memory access request and maintain the object metadata of each object corresponding to the target tree node in the memory node.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 12.

15. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 12.

Images