Memory management method and device, storage medium, and electronic device

Abstract

A memory management method and device, a storage medium, and an electronic device. The method comprises: applying for heap memory for a process from system memory, wherein the process comprises a plurality of threads; for a first thread of the process, using the heap memory to construct a first local free list of the first thread, wherein the first local free list is used for using a thread-local storage structure to store an object pool of the first thread in a thread-local manner; and in response to a memory allocation request, allocating a first object to the first thread from the first local free list.

Description

Memory management methods and devices, storage media, electronic devices

[0001] Cross-references to related applications

[0002] This disclosure claims priority to Chinese Patent Application No. 202510093864.0, filed on January 21, 2025, entitled "Method and Apparatus for Memory Management, Storage Medium, Electronic Device", the entire contents of which are incorporated herein by reference. Technical Field

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

[0004] In related technologies, in high-concurrency real-time systems such as intelligent driving, upstream and downstream tasks need to pass processing results. These processes are usually represented by objects composed of various types of containers. The construction and destruction of these objects involve dynamic memory management. If the new / delete operators provided by the C++ language or the malloc / free interfaces of glibc are used directly for memory management, problems such as large dynamic memory allocation overhead, memory fragmentation, unpredictable system response time, and lock contention in multi-threaded environments will occur due to the high frequency of these allocations and operations.

[0005] No efficient and accurate solution has yet been found to address the aforementioned issues in the relevant technologies. Summary of the Invention

[0006] This invention provides a memory management method and apparatus, storage medium, and electronic device to solve technical problems in related technologies.

[0007] According to an embodiment of the present invention, a memory management method is provided, comprising: requesting heap memory for a process from system memory, wherein the process includes multiple threads; constructing a first local free table for a first thread of the process using the heap memory, wherein the first local free table is used to store an object pool of the first thread in a thread-local storage structure; and allocating a first object for the first thread from the first local free table in response to a memory allocation request.

[0008] Optionally, allocating a first object to the first thread from the first local free table includes: determining whether the first local free table is empty; if the first local free table is not empty, selecting a free object from the head of the first local free table and determining the free object as the first object; and allocating the first object to the first thread.

[0009] Optionally, after determining whether the first local free table is empty, the method further includes: if the first local free table is empty, obtaining the first cross-thread free table of the first thread, wherein the first cross-thread free table is used to reclaim the object pool of the first thread across threads; adding the objects to be reclaimed in the first cross-thread free table to the first local free table; selecting a free object from the head of the first local free table and determining the free object as the first object; and allocating the first object to the first thread.

[0010] Optionally, allocating the first object to the first thread includes: allocating the first object to the first thread; or, allocating the first object to the first thread and passing the first object from the first thread to the calling thread of the first thread.

[0011] Optionally, after allocating the first object from the first local free table, the method further includes: determining a second object to be released by the first thread; determining whether the second object is bound to the first thread; and if the second object is bound to the first thread, adding the second object to the first local free table without locking.

[0012] Optionally, after determining whether the second object is bound to the first thread, the method further includes: if the second object is not bound to the first thread, determining the second thread holding the second object; and returning the second object to the second thread's second cross-thread free table.

[0013] Optionally, returning the second object to the second thread's second cross-thread free table includes: obtaining the old header of the second thread's second cross-thread free table, wherein the old header is of atomic type; storing the second object in the new header of the second cross-thread free table, and linking the old header to the next node of the new header via a pointer; performing an atomic swap operation on the old header; if the atomic swap operation is successful, storing the second object in the head of the second thread's second cross-thread free table.

[0014] Optionally, determining the second object to be released by the first thread includes: monitoring the reference count of the smart pointer of the second object; determining whether the reference count is equal to 0; if the reference count is equal to 0, determining that the second object is the object to be released by the first thread.

[0015] Optionally, constructing the first local free table of the first thread using the heap memory includes: storing the starting address of the heap memory in an object cache area; constructing multiple objects in the object cache area to obtain an object pool for the first thread; adding the multiple objects in the object pool to the first local free table, and constructing an empty first cross-thread free table.

[0016] Optionally, constructing multiple objects in the object cache area includes constructing multiple fixed-length objects in the object cache area.

[0017] According to another embodiment of the present invention, a memory management apparatus is provided, comprising: an application module for applying for heap memory for a process from system memory, wherein the process includes multiple threads; a construction module for constructing a first local free table for a first thread of the process using the heap memory, wherein the first local free table is used to store an object pool of the first thread in a thread-local storage structure; and an allocation module for allocating a first object for the first thread from the first local free table in response to a memory allocation request.

[0018] Optionally, the allocation module includes: a judgment unit, configured to judge whether the first local free table is empty; a first acquisition unit, configured to select a free object from the head of the first local free table if the first local free table is not empty, and determine the free object as the first object; and an allocation unit, configured to allocate the first object to the first thread.

[0019] Optionally, the allocation module further includes: a second acquisition unit, configured to acquire a first cross-thread free table of the first thread if the first local free table is empty before the first acquisition unit selects an idle object from the head of the first local free table and determines the idle object as the first object, wherein the first cross-thread free table is used to reclaim the object pool of the first thread across threads; and an addition unit, configured to add the objects to be reclaimed from the first cross-thread free table to the first local free table.

[0020] Optionally, the allocation unit includes: a first allocation subunit, configured to allocate the first object to the first thread; or, a second allocation subunit, configured to allocate the first object to the first thread and pass the first object from the first thread to the calling thread of the first thread.

[0021] Optionally, the apparatus further includes: a first determining module, configured to determine a second object to be released by the first thread after the allocation module allocates the first object from the first local free table; a judging module, configured to judge whether the second object is bound to the first thread; and an adding module, configured to add the second object to the first local free table without locking if the second object is bound to the first thread.

[0022] Optionally, the device further includes: a second determining module, configured to determine the second thread holding the second object if the second object is not bound to the first thread after the determining module determines whether the second object is bound to the first thread; and a returning module, configured to return the second object to the second thread's second cross-thread free table.

[0023] Optionally, the return module includes: an acquisition unit, configured to acquire the old header of the second cross-thread free table of the second thread, wherein the old header is of atomic type; a first storage unit, configured to store the second object into the new header of the second cross-thread free table, and link the old header to the next node of the new header via a pointer; an operation unit, configured to perform an atomic swap operation on the old header; and a second storage unit, configured to store the second object into the head of the second cross-thread free table of the second thread if the atomic swap operation is successful.

[0024] Optionally, the first determining module includes: a monitoring unit for monitoring the reference count of the smart pointer of the second object; a judging unit for judging whether the reference count is equal to 0; and a determining unit for determining that if the reference count is equal to 0, the second object is an object to be released by the first thread.

[0025] Optionally, the construction module includes: a storage unit for storing the starting address of the heap memory in an object cache area; a construction unit for constructing multiple objects in the object cache area to obtain an object pool for the first thread; and an adding unit for adding multiple objects from the object pool to the first local free table and constructing an empty first cross-thread free table.

[0026] Optionally, the building unit includes a building subunit for building multiple fixed-length objects in the object cache area.

[0027] According to another aspect of the embodiments of this application, a storage medium is also provided, the storage medium including a stored program that executes the above steps when the program is run.

[0028] According to another aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein: the memory is used to store computer programs; and the processor is used to execute the steps in the above method by running the programs stored in the memory.

[0029] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps in the above-described method.

[0030] The beneficial effects of this invention are:

[0031] 1. It solves the problem of memory fragmentation that may occur during the allocation and release of high-concurrency task objects, avoids the generation of memory fragmentation, and at the same time, contiguous virtual memory can increase cache hit rate and improve memory access efficiency.

[0032] 2. It reduces lock contention between multiple threads, improves parallel performance, reduces the overhead of object release, effectively improves the memory management performance of the intelligent driving system, and reduces end-to-end latency. Attached Figure Description

[0033] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0034] Figure 1 is a hardware structure block diagram of a car according to an embodiment of the present invention;

[0035] Figure 2 is a flowchart of a memory management method according to an embodiment of the present invention;

[0036] Figure 3 is an overall layout diagram of the object pool in an embodiment of the present invention;

[0037] Figure 4 is a flowchart of requesting objects from the object pool according to an embodiment of the present invention;

[0038] Figure 5 is a schematic diagram of the first request for an object from the object pool in an embodiment of the present invention;

[0039] Figure 6 is a schematic diagram of requesting an object again from the object pool in an embodiment of the present invention;

[0040] Figure 7 is a flowchart of object release in an embodiment of the present invention;

[0041] Figure 8 is a schematic diagram of a thread releasing objects to the object pool's freelist in an embodiment of the present invention;

[0042] Figure 9 is a schematic diagram of how objects in the freelist to be recycled are recycled to the thread-local freelist after the thread-local freelist of the object pool is used up in an embodiment of the present invention.

[0043] Figure 10 is an overall flowchart of object request and release in an embodiment of the present invention;

[0044] Figure 11 is a structural block diagram of a memory management device according to an embodiment of the present invention. Detailed Implementation

[0045] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present application can be combined with each other.

[0046] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0047] Example 1

[0048] The method embodiment provided in Embodiment 1 of this application can be executed in an automobile, server, processor, autonomous driving / assisted driving / intelligent driving controller, or similar processing device. Taking an automobile as an example, FIG1 is a hardware structure block diagram of an automobile according to an embodiment of the present invention. As shown in FIG1, the automobile may include one or more (only one is shown in FIG1) processors 102 (processor 102 may include, but is not limited to, microprocessors MCU or programmable logic devices FPGA, etc.) and a memory 104 for storing data. Optionally, the automobile may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that the structure shown in FIG1 is only illustrative and does not limit the structure of the automobile. For example, the automobile may also include more or fewer components than shown in FIG1, or have a different configuration than shown in FIG1.

[0049] The memory 104 can be used to store automotive programs, such as application software programs and modules, like the automotive program corresponding to the automotive memory management method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the automotive program stored in the memory 104, thus implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the vehicle via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a vehicle's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0051] This embodiment provides a memory management method. Figure 2 is a flowchart of a memory management method according to an embodiment of the present invention. As shown in Figure 2, the process includes the following steps:

[0052] Step S202: Allocate heap memory for the process from system memory, wherein the process includes multiple threads;

[0053] Optionally, the heap memory can be contiguous in the address space, and a certain amount of heap memory contiguous in the process address space can be requested from the system in advance.

[0054] Step S204: For the first thread of the process, construct a first local free table for the first thread using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread-local storage structure.

[0055] The object pool in this embodiment includes multiple objects, and each object in the object pool corresponds to a memory resource.

[0056] Step S206: In response to the memory allocation request, allocate a first object for the first thread from the first local free table.

[0057] Through the above steps, heap memory for a process is requested from system memory, wherein the process includes multiple threads; for the first thread of the process, a first local free table is constructed using the heap memory, wherein the first local free table is used to store the object pool of the first thread in a thread-local storage structure; in response to the memory allocation request, a first object is allocated for the first thread from the first local free table. By using the thread-local free table to allocate objects to the thread without locking, the technical problem of memory fragmentation in dynamic memory allocation in related technologies is solved, thereby improving memory management efficiency and performance.

[0058] In this embodiment, constructing the first local free table of the first thread using the heap memory includes: storing the starting address of the heap memory in an object cache area; constructing multiple objects in the object cache area to obtain an object pool for the first thread; adding the multiple objects in the object pool to the first local free table, and constructing an empty first cross-thread free table.

[0059] Optionally, each object in the object pool has the same length, and constructing multiple objects in the object cache area includes: constructing multiple fixed-length objects in the object cache area.

[0060] Figure 3 is an overall layout diagram of the object pool in this embodiment of the invention. The thread object pool includes three objects, obj1 to obj3, and consists of two freelists: a freelist based on thread-local storage (local free list) and a freelist for cross-thread object return (cross-thread free list), as well as an object buffer with contiguous virtual addresses. During the initialization phase, the object pool requests heap memory from the system at once, which can accommodate a number of objects, according to the user's configuration. The starting address of this memory region is stored in the object buffer member. Then, based on the C++ placementnew operation, several objects are constructed in this buffer region. At the same time, the object pool adds the newly constructed objects to the freelist based on thread-local storage, and the freelist for return is empty.

[0061] Memory fragmentation is caused by applications frequently allocating and releasing memory blocks of varying sizes. This embodiment solves this problem by allocating and releasing memory in units of fixed length (objects). First, based on the object size and a pre-determined upper limit on the number of objects, a certain amount of contiguous heap memory in the process address space is pre-allocated from the system memory. The corresponding number of objects are then constructed in this memory area using C++'s placement new technique. The allocation and release of these objects can then be controlled. Using C++'s template technique, the object pool is implemented as a template class, allowing it to be applied to every data structure that requires it. Since allocation and release are done on an object-by-object basis, memory fragmentation can be avoided. Furthermore, contiguous virtual memory increases cache hit rate and improves memory access efficiency.

[0062] In one embodiment of this example, allocating a first object to the first thread from the first local free table includes: determining whether the first local free table is empty; if the first local free table is not empty, selecting a free object from the head of the first local free table and determining the free object as the first object; and allocating the first object to the first thread.

[0063] In another implementation of this example, before selecting an idle object from the head of the first local free table and identifying the idle object as the first object, the method further includes: if the first local free table is empty, obtaining the first cross-thread free table of the first thread, wherein the first cross-thread free table is used to reclaim the object pool of the first thread across threads; and adding the objects to be reclaimed in the first cross-thread free table to the first local free table.

[0064] After constructing the object pool, users can begin using it to request objects. Figure 4 is a flowchart of requesting objects from the object pool according to an embodiment of the present invention. To reduce contention for the global lock when multiple threads operate on the same freelist in a multi-threaded scenario, the present invention maintains a separate object pool for each thread that needs to request objects, and uses thread-local storage as the storage structure of the freelist. In this way, object requests can be made directly from the thread-local object pool. If the local freelist is not empty, the head object of the local freelist is directly allocated. Since this process operates in thread-specific memory, no locking is required. If the local freelist is empty, it means that all objects have been allocated. At this time, there must be available objects in the freelist to be reclaimed (otherwise, there is a problem with the program processing flow, and it is necessary to investigate why downstream tasks do not release objects to the freelist to be reclaimed).

[0065] Figure 5 is a schematic diagram of the first request for an object from the object pool in an embodiment of the present invention. The requested object is obj1. Figure 6 is a schematic diagram of the second request for an object from the object pool in an embodiment of the present invention. Based on Figure 6, it can be seen that the second requested object is obj2. At this time, the remaining available idle object in the object pool is obj3.

[0066] Optionally, allocating the first object to the first thread includes: allocating the first object to the first thread; or, allocating the first object to the first thread and passing the first object from the first thread to the calling thread of the first thread.

[0067] Objects in the object pool of the first thread can be allocated to the first thread itself, or to the calling thread that calls the first thread, to achieve memory sharing and calling between threads.

[0068] In one embodiment of this example, after allocating the first object from the first local free table, the method further includes: determining a second object to be released by the first thread; determining whether the second object is bound to the first thread; and if the second object is bound to the first thread, adding the second object to the first local free table without locking.

[0069] Since the first local free table uses a thread-local storage structure, the second object can be added to the first local free table without locking.

[0070] In another implementation scenario based on this embodiment, after determining whether the second object is bound to the first thread, the method further includes: if the second object is not bound to the first thread, determining the second thread holding the second object; and returning the second object to the second thread's second cross-thread free table.

[0071] Figure 7 is a flowchart of object release in an embodiment of the present invention. Object release is divided into two cases. If the thread releasing the object is the holder of the object pool (holding thread), no locking is required, and the object is directly added to the head of the thread pool. Otherwise, the object is placed at the head of the freelist to be reclaimed in the holder's object pool through a CAS (compare-and-swap) operation, waiting for the object pool holding thread to reclaim it. The object pool holding thread will reclaim the object to be reclaimed into its local freelist all at once through a CAS operation when its local freelist is empty. In this way, through batch and delayed reclamation, the probability of threads accessing the freelist to be reclaimed at the same time is reduced, the probability of atomic operations needing to be retried is small, and the overhead is very small, which can further improve memory management efficiency.

[0072] Figure 8 is a schematic diagram of a thread releasing objects to the freelist of the object pool in an embodiment of the present invention. The object returned across threads is obj1. Since the user thread is not the object pool holding thread, CAS operation is required to reclaim the object. However, since the object pool holding thread only reclaims objects from the freelist in batches when its local freelist is empty, the probability of a race condition between the two threads is very small. Therefore, the atomic CAS operation is very efficient.

[0073] Figure 9 is a schematic diagram of how objects in the thread-local freelist of the object pool are recycled to the thread-local freelist after the thread-local freelist of the object pool is used up in an embodiment of the present invention. At this time, object obj3 is still in use.

[0074] In one example, returning the second object to the second thread's second cross-thread free table includes: obtaining the old header of the second thread's second cross-thread free table, wherein the old header is of atomic type; storing the second object in the new header of the second cross-thread free table, and linking the old header to the next node of the new header via a pointer; performing an atomic swap operation on the old header; if the atomic swap operation is successful, storing the second object in the head of the second thread's second cross-thread free table.

[0075] Optionally, the pointer is a next pointer, used to link the old table head to the next node of the new table head via the next pointer.

[0076] This embodiment uses thread-local storage, allocating two separate freelists—one thread-local and one cross-thread—for each thread that needs to allocate an object. When a thread allocates or releases an object, it operates on the thread-local freelist, eliminating the need for locking. For cross-thread object releases (i.e., the object's allocation and release occur in different threads), the releasing thread uses a C++ atomic CAS operation to return the object to the other cross-thread freelist.

[0077] The process of returning an object based on CAS operation is as follows: The thread returning the object first obtains the old freelist header (the old freelist header is an atomic type); secondly, the thread returning the object stores the object to be returned into the new header and links the old header to the next node of the new header through the next pointer; the thread returning the object performs a compare_exchange operation on the atomic old header (this operation is an atomic operation). This operation takes the expected value of the header address, the updated value (the new header address), and the memory order as input. If the operation fails, it means that another thread has modified the header during the process of obtaining the old header and performing the compare_exchange operation, and it needs to be retried.

[0078] The corresponding pseudocode is as follows:

[0079] When the thread managing the freelist finishes using its local freelist, it can add the entire cross-thread freelist to the thread-local freelist all at once. By using thread-local freelists, cross-thread freelists, and batch recycling techniques, lock contention between multiple threads is reduced, improving parallel performance and reducing the overhead of object release.

[0080] Optionally, determining the second object to be released by the first thread includes: monitoring the reference count of the smart pointer of the second object; determining whether the reference count is equal to 0; if the reference count is equal to 0, determining that the second object is the object to be released by the first thread.

[0081] When objects need to be reclaimed, requiring users to manually release them may lead to object pool leaks (if the object pool has no free blocks). This embodiment encapsulates the raw pointers of objects in the object pool into smart pointers. By using reference counting and overriding the smart pointer's deleter, automatic object reclamation is achieved. The process of automatic object reclamation using smart pointers through reference counting and a custom deleter is as follows:

[0082] 1. Create a smart pointer. This includes initializing the control block, setting the reference count, and configuring the deleter;

[0083] 2. Modify the reference count;

[0084] - Added: When a smart pointer is copied or duplicated, a new `shared_ptr` is created.

[0085] - Reduce: `shared_ptr` goes out of scope or displays `reset()`.

[0086] 3. Check the reference count;

[0087] - If the reference count is greater than 0: the resource is still in use.

[0088] - If the reference count is 0: call the deleter to release the resource.

[0089] 4. Custom deleter to release resources.

[0090] - Invoke the specified deleter (function pointer, lambda, etc.)

[0091] Objects passed between tasks such as autonomous driving often contain many container members. In order to reduce the overhead of memory allocation within the container, the object's custom deleter needs to retain the memory of the container members inside the object and only perform a reset operation on the container.

[0092] Figure 10 is an overall flowchart of object allocation and release in an embodiment of the present invention. When a thread allocates an object for the first time, an object pool and its corresponding data structure can be constructed. This data structure is used to store the memory area of ​​the object, manage the local freelist of the object, and the pending freelist for returning objects across threads. Based on this, the head of the local freelist is removed, and the object managed by it is returned to the user. If the local freelist is empty, it means that the object pool has no free objects, and the pending freelist needs to be checked. If the pending freelist is also empty, there is a risk of resource leakage in the use of the object pool, and the allocation and release logic needs to be checked. If the pending freelist is not empty, it is added to the local freelist, and an object is returned to the user from the local freelist. During object reclamation, the reclamation interface can determine whether it is a reclamation thread and whether it is the thread holding the object based on the object's metadata and the thread ID of the reclamation thread. If so, the object is directly returned to the head of the local freelist of the object pool; otherwise, the object is returned to the head of the pending freelist through a CAS operation.

[0093] The memory management scheme adopted in this embodiment solves the problems of memory fragmentation and multi-threaded lock contention that may occur during the allocation and release of objects in high-concurrency tasks of intelligent driving by allocating and releasing memory on an object-by-object basis, and by using thread-local storage of freelists and cross-thread freelists to be reclaimed, as well as corresponding atomic CAS operations. This effectively improves the memory management performance of the intelligent driving system and reduces end-to-end latency.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0095] Example 2

[0096] This embodiment also provides a memory management device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0097] Figure 11 is a structural block diagram of a memory management device according to an embodiment of the present invention. As shown in Figure 11, the device includes:

[0098] The request module 110 is used to request heap memory for a process from system memory, wherein the process includes multiple threads;

[0099] Construction module 112 is used to construct a first local free table for the first thread of the process using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread local using a thread-local storage structure.

[0100] The allocation module 114 is used to respond to a memory allocation request and allocate a first object for the first thread from the first local free table.

[0101] Optionally, the allocation module includes: a judgment unit, configured to judge whether the first local free table is empty; a first acquisition unit, configured to select a free object from the head of the first local free table if the first local free table is not empty, and determine the free object as the first object; and an allocation unit, configured to allocate the first object to the first thread.

[0102] Optionally, the allocation module further includes: a second acquisition unit, configured to acquire a first cross-thread free table of the first thread if the first local free table is empty before the first acquisition unit selects an idle object from the head of the first local free table and determines the idle object as the first object, wherein the first cross-thread free table is used to reclaim the object pool of the first thread across threads; and an addition unit, configured to add the objects to be reclaimed from the first cross-thread free table to the first local free table.

[0103] Optionally, the allocation unit includes: a first allocation subunit, configured to allocate the first object to the first thread; or, a second allocation subunit, configured to allocate the first object to the first thread and pass the first object from the first thread to the calling thread of the first thread.

[0104] Optionally, the apparatus further includes: a first determining module, configured to determine a second object to be released by the first thread after the allocation module allocates the first object from the first local free table; a judging module, configured to judge whether the second object is bound to the first thread; and an adding module, configured to add the second object to the first local free table without locking if the second object is bound to the first thread.

[0105] Optionally, the device further includes: a second determining module, configured to determine the second thread holding the second object if the second object is not bound to the first thread after the determining module determines whether the second object is bound to the first thread; and a returning module, configured to return the second object to the second thread's second cross-thread free table.

[0106] Optionally, the return module includes: an acquisition unit, configured to acquire the old header of the second cross-thread free table of the second thread, wherein the old header is of atomic type; a first storage unit, configured to store the second object into the new header of the second cross-thread free table, and link the old header to the next node of the new header via a pointer; an operation unit, configured to perform an atomic swap operation on the old header; and a second storage unit, configured to store the second object into the head of the second cross-thread free table of the second thread if the atomic swap operation is successful.

[0107] Optionally, the first determining module includes: a monitoring unit for monitoring the reference count of the smart pointer of the second object; a judging unit for judging whether the reference count is equal to 0; and a determining unit for determining that if the reference count is equal to 0, the second object is an object to be released by the first thread.

[0108] Optionally, the construction module includes: a storage unit for storing the starting address of the heap memory in an object cache area; a construction unit for constructing multiple objects in the object cache area to obtain an object pool for the first thread; and an adding unit for adding multiple objects from the object pool to the first local free table and constructing an empty first cross-thread free table.

[0109] Optionally, the building unit includes a building subunit for building multiple fixed-length objects in the object cache area.

[0110] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0111] Example 3

[0112] Embodiments of the present invention also provide a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0113] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0114] S1, request heap memory for the process from system memory, wherein the process includes multiple threads;

[0115] S2, for the first thread of the process, the first local free table of the first thread is constructed using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread local using a thread-local storage structure;

[0116] S3, in response to the memory allocation request, allocate a first object for the first thread from the first local free table.

[0117] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0118] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0119] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0120] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0121] S1, request heap memory for the process from system memory, wherein the process includes multiple threads;

[0122] S2, for the first thread of the process, the first local free table of the first thread is constructed using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread local using a thread-local storage structure;

[0123] S3, in response to the memory allocation request, allocate a first object for the first thread from the first local free table.

[0124] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0125] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0126] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0127] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0128] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A memory management method, characterized in that, include: Allocate heap memory from system memory for a process, wherein the process comprises multiple threads; For the first thread of the process, the first local free table of the first thread is constructed using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread-local storage structure. In response to a memory allocation request, allocate a first object for the first thread from the first local free table.

2. The method according to claim 1, characterized in that, Allocating a first object for the first thread from the first local free table includes: Determine if the first local free table is empty; If the first local free table is not empty, select a free object from the head of the first local free table and determine the free object as the first object; Allocate the first object for the first thread.

3. The method according to claim 2, characterized in that, Before selecting a free object from the head of the first local free table and identifying the free object as the first object, the method further includes: If the first local free table is empty, obtain the first cross-thread free table of the first thread, wherein the first cross-thread free table is used to recycle the object pool of the first thread across threads; Add the objects to be recycled from the first cross-thread free table to the first local free table.

4. The method according to any one of claims 2 or 3, characterized in that, Allocating a first object to the first thread includes: Allocate the first object to the first thread; or, The first object is allocated to the first thread, and the first object is passed from the first thread to the calling thread of the first thread.

5. The method according to any one of claims 1 to 4, characterized in that, After allocating the first object from the first local free table, the method further includes: Determine the second object to be released by the first thread; Determine whether the second object is bound to the first thread; If the second object is bound to the first thread, add the second object to the first local free table without locking.

6. The method according to claim 5, characterized in that, After determining whether the second object is bound to the first thread, the method further includes: If the second object is not bound to the first thread, determine the second thread that holds the second object; Return the second object to the second cross-thread free table of the second thread.

7. The method according to claim 6, characterized in that, The second cross-thread free list that returns the second object to the second thread includes: Obtain the old header of the second cross-thread free table of the second thread, wherein the old header is of atomic type; Store the second object into the new head of the second cross-thread free table, and link the old head to the next node of the new head via a pointer; Perform an atomic exchange operation on the old header; If the atomic swap operation is successful, the second object is stored in the head of the second thread's second cross-thread free table.

8. The method according to any one of claims 5 to 7, characterized in that, The second object to be released by the first thread includes: Monitor the reference count of the smart pointer of the second object; Determine if the reference count is equal to 0; If the reference count is equal to 0, the second object is determined to be the object to be released by the first thread.

9. The method according to any one of claims 1 to 8, characterized in that, Constructing the first local free table of the first thread using the heap memory includes: The starting address of the heap memory is stored in the object cache area; Multiple objects are constructed in the object cache area to obtain the object pool of the first thread; Add multiple objects from the object pool to the first local free table, and construct an empty first cross-thread free table.

10. The method according to claim 9, characterized in that, Building multiple objects in the object cache area includes: Multiple fixed-length objects are constructed in the object cache area.

11. A memory management device, characterized in that, include: The request module is used to request heap memory from system memory for a process, wherein the process includes multiple threads; A construction module is used to construct a first local free table for the first thread of the process using the heap memory, wherein the first local free table is used to store the object pool of the first thread in the thread-local storage structure. The allocation module is used to respond to memory allocation requests and allocate a first object for the first thread from the first local free table.

12. The apparatus according to claim 11, characterized in that, The device further includes: The determining module is configured to determine a second object to be released by the first thread after the allocation module allocates a first object from the first local free table; The judgment module is used to determine whether the second object is bound to the first thread; An add module is provided to add the second object to the first local free table without locking if the second object is bound to the first thread.

13. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method described in any one of claims 1 to 10 when it is run.

14. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 10.

Images