A dispenser, memory allocation method, memory release method, and electronic device

Abstract

This invention discloses an allocator, a memory allocation and release method for optimizing the jitter performance of dynamic memory allocation. The allocator includes a heap memory partitioning module, a round-robin allocation scheduling module, a memory allocation execution module, and a memory release module. The memory allocation method divides the available heap memory of the real-time operating system into several independent memory pools. After receiving an allocation request, it selects the target memory pool based on a round-robin counter and performs the allocation. The memory release method determines the memory pool based on the memory pointer and returns the memory block to the corresponding free data structure. This invention improves system throughput and concurrency by distributing allocation requests through multiple independent memory pools combined with round-robin scheduling. Round-robin scheduling has O(1) deterministic time overhead, stabilizes allocation time, and accurately defines the worst-case execution time, meeting the deterministic requirements of real-time systems. The memory pools achieve physical isolation of data structures, reducing access latency.

Description

Technical Field

[0001] This invention belongs to the field of memory allocation technology, specifically relating to an allocator, a memory allocation method, a memory release method, and an electronic device. Background Technology

[0002] Real-time operating systems, such as UniProton [https: / / atomgit.com / openeuler / UniProton], have strict requirements for the determinism of task execution. The time overhead of memory allocation operations must have a predictable upper limit to avoid introducing uncontrollable "jitter," which is the fluctuation in the time required for multiple allocation operations (the difference between the maximum and minimum time required for multiple allocation operations). Traditional memory allocation algorithms, such as the Buddy System or Segregated Free List in dynamic memory allocation, although having good average performance, may experience significant increases in execution time in the worst case due to operations such as searching, splitting, and merging free blocks, leading to performance jitter.

[0003] Specifically, UniProton's FSC memory allocation algorithm is an optimized isolated free list algorithm. Its basic principle is to divide the heap memory into multiple free lists with fixed granularity (e.g., 16 bytes, 32 bytes, 64 bytes, etc.), with each list managing free memory blocks within a specific size range. When a memory allocation request is made, the allocator finds the corresponding free list based on the requested size and allocates a free block from the head of the list; upon release, the memory block is returned to the corresponding list.

[0004] Although UniProton's FSC algorithm offers a significant speed improvement over traditional dynamic allocation algorithms, performance fluctuations still exist in certain scenarios, mainly in the following aspects: 1. Lock contention caused by singly linked list contention: In existing FSC implementations, each bin typically corresponds to a free list. In multi-core, multi-threaded, or multi-tasking environments, when multiple execution entities simultaneously request the allocation or release of memory of the same bin, the free list of that bin must be locked to prevent data contention. This lock contention can lead to task blocking, especially in high-concurrency scenarios, where lock contention intensifies, increasing the unpredictability of allocation time and causing significant performance fluctuations.

[0005] 2. Performance bottleneck caused by hotspot linked lists: In certain application scenarios, memory allocation requests of a specific size can occur very frequently (e.g., frequent allocation and release of 64-byte data packets). This can cause the corresponding free list to become a "hotspot," where all accesses to that size of memory are concentrated. Even with fine-grained locks, serialized accesses on this hotspot linked list can limit the system's concurrent processing capabilities, leading to a decrease in overall throughput and increased volatility in allocation latency.

[0006] 3. Cache locality problem: Frequent access to the same free list can cause related memory management data structures to become invalid frequently in the CPU cache. When one core modifies the head of the list, the cache lines of other cores will become invalid and need to be read from memory again, which further increases the latency and uncertainty of memory access.

[0007] In summary, existing technologies suffer from problems such as intense lock contention, concentrated hotspots, and large performance fluctuations when facing high concurrency and high frequency memory allocation requests, making it difficult to meet the stringent requirements of real-time systems for high determinism and low jitter. Summary of the Invention

[0008] To overcome the above-mentioned technical defects, the present invention provides an allocator, a memory allocation method, a memory release method, and an electronic device, which can effectively suppress memory allocation jitter and improve multi-core concurrency performance.

[0009] This invention is achieved in the following ways: An allocator that optimizes the thrashing performance of dynamic memory allocation includes: The heap memory partitioning module is used to divide the heap memory space available to the real-time operating system into several independent memory pools; The round-robin allocation scheduling module is used to maintain the round-robin counter. Based on the current value of the round-robin counter, it selects the target independent memory pool from several independent memory pools based on the allocation request, and records the index of the memory pool to be selected for the next allocation operation. The memory allocation execution module is used to call the allocation algorithm, perform memory allocation in the target independent memory pool, and return a memory pointer to the requester; The memory release module is used to return memory blocks to the free list based on release requests and by calling the release algorithm according to the memory pointer.

[0010] As a further improvement of the present invention, the present invention also includes: The error handling module either migrates memory from other independent memory pools or returns an allocation failure message to the requester when there is insufficient space in a particular independent memory pool to satisfy the allocation request.

[0011] This invention provides a memory allocation method to optimize the thrashing performance of dynamic memory allocation, implemented using the aforementioned allocator, comprising: The available heap memory space in the real-time operating system is divided into several independent memory pools; Receive memory allocation requests; Based on the current rotation counter value, select the target independent memory pool from several independent memory pools; Within the target independent memory pool, the allocation algorithm is invoked to perform memory allocation operations; Return the allocated memory pointer to the requester.

[0012] As a further improvement of the present invention, when receiving a memory allocation request, if it is determined that the allocation request is invalid, an error value is returned to the requester.

[0013] As a further improvement of the present invention, the present invention also includes the step of: determining the return result of the memory allocation operation; if the allocation result is a memory block of the required size in the allocation request, then obtaining the memory pointer. If the allocation fails, an error value is returned to the requester; Alternatively, if allocation fails, the process returns to the step of selecting a target independent memory pool from several independent memory pools based on the current rotation counter value, and memory reallocation is performed.

[0014] This invention provides a memory release method to optimize the performance of dynamic memory allocation jitter, characterized by employing the aforementioned allocator, comprising: Receive a memory release request that includes a memory pointer; Determine the independent memory pool to which the memory pointer belongs; The release algorithm is invoked within the respective independent memory pool to return the memory block pointed to by the memory pointer to the free data structure of the respective independent memory pool.

[0015] As a further improvement of the present invention, when receiving a memory release request that includes a memory pointer, if it is determined that the memory release request is invalid, an error value is returned to the requester.

[0016] As a further improvement of the present invention, the step of determining the independent memory pool to which the memory pointer belongs includes: Traverse all independent memory pools and check if the memory pointer is located between the start and end addresses of a certain independent memory pool. If a memory pointer is found, record the corresponding memory pool index. Alternatively, if the identifier of the independent memory pool to which the memory pointer belongs has been stored during the memory allocation phase, the memory pool index is read from the metadata near the memory pointer.

[0017] As a further improvement of the present invention, if the memory pool to which the memory pointer belongs cannot be determined, error handling is performed.

[0018] The present invention also provides an electronic device, 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; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the allocator, the memory allocation method, and the memory release method described above.

[0019] Compared with existing technologies, the beneficial effects of this invention are as follows: It divides the overall heap memory into multiple independent memory pools, distributes allocation requests through round-robin allocation scheduling, and decomposes lock contention concentrated in a single free list into independent contention across multiple pools. This effectively reduces the blocking probability in multi-task, high-concurrency scenarios and improves system throughput and concurrent processing capabilities in multi-core environments. Round-robin allocation scheduling has O(1) deterministic time overhead, avoiding time fluctuations caused by serial access to hot lists, lock waiting, and free block searches, making memory allocation time more stable. The worst-case execution time can be precisely defined, fully meeting the core requirements of real-time operating systems for deterministic task execution. Distributing memory operations to independent memory pools achieves physical isolation of data structures and reduces access latency. Attached Figure Description

[0020] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein: Figure 1 This is a schematic diagram of the structure of the distributor described in this invention; Figure 2 This is a flowchart of the memory allocation method described in this invention; Figure 3 This is another flowchart of the memory allocation method described in this invention; Figure 4 This is a flowchart of the memory release method described in this invention; Figure 5 This is another flowchart of the memory release method described in this invention. Detailed Implementation

[0021] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0022] This invention provides an allocator that optimizes the thrashing performance of dynamic memory allocation, such as... Figure 1 As shown, it includes: a heap memory partitioning module, a round-robin allocation and scheduling module, a memory allocation and execution module, and a memory release module.

[0023] The heap memory partitioning module is used to divide the heap memory space available to the real-time operating system into N independent memory pools. The N independent memory pools are of equal or approximately the same size, where N is an integer greater than 1. For example, the entire heap can be divided into two, four, or more independent memory pools. Each independent memory pool has its own independent metadata management structure. For example, in an implementation based on the FSC algorithm, each independent memory pool has its own independent set of free list arrays (bins) and corresponding bitmaps or other management data structures.

[0024] The round-robin allocation scheduling module maintains a round-robin counter. Based on the current value of the round-robin counter, it selects a target independent memory pool from N independent memory pools based on the allocation request, and records the index of the memory pool to be selected for the next allocation operation. When a memory allocation request is received, the round-robin allocation scheduling module selects one of the N independent memory pools for allocation based on the current value of the round-robin counter, and updates the round-robin counter to point to the next independent memory pool, thereby realizing the round-robin scheduling of allocation requests among multiple independent memory pools.

[0025] The memory allocation execution module invokes the allocation algorithm, performs memory allocation within the target independent memory pool, retrieves a suitable memory block from the corresponding free list and returns it to the requester, along with a memory pointer. Simultaneously, it needs to record the target independent memory pool used so that the correct independent memory pool can be found during memory release. The allocation algorithm is an internal allocation algorithm of the target independent memory pool, such as the FSC algorithm.

[0026] The memory release module is used to return memory blocks to the free list based on release requests and by invoking a release algorithm according to the memory pointer. Specifically, when a memory pointer to be released is received, the memory release module needs to determine which independent memory pool the memory pointer originally belonged to. This can be determined by recording metadata during allocation (such as storing the pool ID at the beginning or end of the allocated memory block) or by comparing the pointer with the address range of each independent memory pool. After determining the independent memory pool, the release algorithm within that independent memory pool is invoked to return the memory block to its corresponding free list.

[0027] It should be noted that the number N of independent memory pools can be configured based on the number of CPU cores in the system. For example, it can be set to the same as the number of CPU cores, or an integer multiple of the number of cores, to maximize the utilization of multi-core parallel processing capabilities. Each core can then tend to handle requests allocated to different independent memory pools, thereby minimizing lock contention.

[0028] Furthermore, the present invention also includes an error handling module, which, when an independent memory pool does not have sufficient space to satisfy an allocation request, migrates memory from other independent memory pools or returns an allocation failure to the requester. That is, when the target independent memory pool selected by the round-robin allocation scheduling module does not have sufficient space to satisfy the current allocation request, the error handling module can handle the situation according to a predefined strategy, such as attempting to borrow / migrate memory from other independent memory pools with free space, or directly returning an allocation failure. In real-time systems, returning an allocation failure is more commonly used to ensure system simplicity and determinism.

[0029] This invention divides a single heap space into several independent memory pools using a heap memory partitioning module. Combined with a round-robin allocation scheduling module, allocation requests are distributed across these independent memory pools. This architecture distributes contention, originally concentrated on a global lock, across multiple independent memory pools. In a multi-core or multi-threaded environment, different cores or threads can perform allocation operations simultaneously in different memory pools without waiting for each other. For example, in a dual-memory-pool scenario, lock contention intensity is reduced. This significantly reduces the time overhead caused by tasks spinning or blocking while waiting for locks, substantially improving the overall system throughput and concurrency capabilities.

[0030] To address the stringent deterministic requirements of real-time operating systems for task execution, this invention effectively suppresses performance jitter in memory allocation by eliminating hotspot linked lists. Since the round-robin scheduling mechanism itself has a deterministic O(1) time complexity and avoids the unpredictable delays caused by traversing, splitting, and merging free blocks in traditional algorithms, the difference between the maximum and minimum memory allocation times (i.e., jitter) is significantly reduced. Tasks no longer experience random delays due to lock contention or complex linked list operations, making the worst-case execution time of memory allocation operations easier to predict and define, thus meeting the core requirements of low latency and high determinism in scenarios such as industrial control.

[0031] This invention provides a memory allocation method to optimize the thrashing performance of dynamic memory allocation, implemented using the aforementioned allocator, such as... Figure 2 and Figure 3 As shown, it includes: S101. Divide the available heap memory space in the real-time operating system into N independent memory pools. The N independent memory pools are of equal or approximately the same size, where N is an integer greater than 1. For example, the entire heap can be divided into two, four, or more independent memory pools. Each independent memory pool has its own independent metadata management structure. For example, in an implementation based on the FSC algorithm, each independent memory pool has its own independent set of free list arrays (bins) and corresponding bitmaps or other management data structures.

[0032] S102. Receive a memory allocation request. At the same time, the validity of the memory allocation request needs to be judged. If the memory allocation request is judged to be valid, proceed to step S103. If the memory allocation request is judged to be invalid, return an error value to the requester.

[0033] S103. Based on the current round-robin counter value, select the target independent memory pool from several independent memory pools. During this process, the allocator atomically reads the current round-robin counter value, denoted as current_pool. This counter indicates the index of the memory pool that should be preferentially selected for this allocation. According to the value of current_pool, select the corresponding memory pool (denoted as Pool[current_pool]) from the N pre-allocated independent memory pools.

[0034] S104. In the target independent memory pool Pool[current_pool], call the allocation algorithm to perform memory allocation operations and attempt to acquire a memory block of size size.

[0035] After performing the memory allocation operation, the return result of the memory allocation operation is determined. If the allocation result is a memory block of the required size in the memory allocation request, a memory pointer is obtained. If the allocation fails, a preset error handling strategy is executed. In one implementation, a NULL pointer can be returned directly to indicate allocation failure. In another implementation, a re-allocation attempt can be made in another memory pool, i.e., returning to step S103 (shown by the dotted line in the figure) and selecting another target independent memory pool. However, it should be noted that such retries may affect determinism, so they are usually not used in high real-time scenarios and an error is returned directly.

[0036] S105. Return the allocated memory pointer to the requester, and the memory allocation process ends.

[0037] This invention provides a memory release method to optimize the thrashing performance of dynamic memory allocation, characterized by employing the aforementioned allocator, such as... Figure 4 and Figure 5 As shown, it includes: S201. Receive a memory release request including a memory pointer. At the same time, it is necessary to determine the validity of the memory release request. If the memory release request is found to be valid, proceed to step S202. If the memory release request is found to be invalid, return an error value to the requester.

[0038] S202. Determine the independent memory pool to which the memory pointer belongs. Step S202 can be implemented in any of the following ways: 1. Traverse all independent memory pools and check if the memory pointer is located between the start and end addresses of a certain independent memory pool. If a memory pointer is found, record the corresponding memory pool index. 2. If the identifier of the independent memory pool to which the memory pointer belongs has been stored at the beginning or end of the independent memory pool block during the memory allocation phase, then the memory pool index is read from the metadata near the memory pointer.

[0039] Determine whether the memory pointer has found its own independent memory pool, i.e., whether the memory pool index is a valid index. If found, proceed to step S203. If not found, such as if the memory pointer is an invalid pointer or does not belong to any independent memory pool, perform error handling, such as ignoring the release request or logging the error.

[0040] S203. In the independent memory pool to which the memory pointer belongs, the release algorithm is called to return the memory block pointed to by the memory pointer to the free data structure of the independent memory pool to which the memory release process ends.

[0041] The invention will now be described in detail with reference to specific implementation processes: As one implementation, the dispenser of the present invention is based on UniProton. Its core data structure and implementation are as follows (described in C language pseudocode): Internal auxiliary functions The functions in the original FSC that operate on global linked lists / bitmaps have been modified to accept FscMemPool* parameters so that they can operate on a specified pool.

[0042] / / Remove a free block from the linked list of the specified pool static inline void OsFscMemDeleteInPool(FscMemPool *pool, structTagFscMemCtrl *currBlk) { currBlk->next->prev = currBlk->prev; currBlk->prev->next = currBlk->next; } / / Insert a free block into the linked list of the specified pool and update the bitmap. static inline void OsFscMemInsertInPool(FscMemPool *pool, struct TagFscMemCtrl *currBlk, struct TagFscMemCtrl *fscFreeList, atomic_uint *bitMapPtr) { U32 idx = OS_FSC_MEM_SZ2IDX(currBlk->size); struct TagFscMemCtrl *headBlk =&(fscFreeList[idx]); / / Atomically update the bitmap (or use normal assignment with locking) atomic_fetch_or(bitMapPtr, OS_FSC_MEM_IDX2BIT(idx)); currBlk->prev = headBlk; currBlk->next = headBlk->next; headBlk->next->prev = currBlk; headBlk->next = currBlk; } / / Search for suitable free blocks in the specified pool (pooled version of the original OsFscMemSearch) static struct TagFscMemCtrl *OsFscMemSearchInPool(FscMemPool *pool,U32 size, U32 *idx) { U32 staIdx = OS_FSC_MEM_SZ2IDX(size); *idx = staIdx + 1; atomic_uint bitMap = atomic_load(&pool->bitMap); while (1) { *idx = OsGetLmb1((bitMap<<*idx)>>*idx); if (OS_FSC_MEM_LAST_IDX<= *idx) { *idx = staIdx; struct TagFscMemCtrl *headBlk =&pool->freeListHeads[*idx]; struct TagFscMemCtrl *currBlk = headBlk->next; while (currBlk != headBlk) { if (OS_FSC_MEM_SZGET(currBlk)>= size) { return currBlk; } currBlk = currBlk->next; } return NULL; / / No memory available } struct TagFscMemCtrl *headBlk =&pool->freeListHeads[*idx]; if (headBlk->next == headBlk) { / / This linked list is empty, clear the corresponding bitmap. atomic_fetch_and(&pool->bitMap, ~OS_FSC_MEM_IDX2BIT(*idx)); bitMap = atomic_load(&pool->bitMap); / / Reload } else { return headBlk->next; } } } Distributor initialization The given total heap memory is divided equally into two pools, and the pooled version of the original OsFscMemInit is called to initialize them respectively.

[0043] U32 JitterReducedAllocatorInit(uintptr_t totalAddr, U32 totalSize) { if (totalAddr == 0 || totalSize<2 * OS_FSC_MEM_MIN_SIZE) { return OS_ERRNO_MEM_INITADDR_ISINVALID; } U32 poolSize = totalSize / 2; / / Ensure alignment poolSize = poolSize&~(OS_FSC_MEM_SIZE_ALIGN - 1); / / Initialize pool 0 U32 ret = OsFscMemPoolInit(&g_jrAllocator.pools[0], totalAddr,poolSize); if (ret != OS_OK) return ret; / / Initialize pool 1 ret = OsFscMemPoolInit(&g_jrAllocator.pools[1], totalAddr + poolSize,totalSize - poolSize); if (ret != OS_OK) return ret; atomic_init(&g_jrAllocator.roundRobinCounter, 0); return OS_OK; } / / Pool initialization function (modified from the original OsFscMemInit) static U32 OsFscMemPoolInit(FscMemPool *pool, uintptr_t addr, U32size) { / / Validity check omitted (same as original code) / / ... / / Clear memory area (void)memset_s((void *)addr, size, 0, size); / / Initialize the head of the free linked list (each head points to itself) for (U32 idx = 0; idx <OS_FSC_MEM_LAST_IDX; idx++) { pool->freeListHeads[idx].prev =&pool->freeListHeads[idx]; pool->freeListHeads[idx].next =&pool->freeListHeads[idx]; } / / Calculate available size and set starting block size -= OS_FSC_MEM_USED_HEAD_SIZE; U32 idx = OS_FSC_MEM_SZ2IDX(size); atomic_init(&pool->bitMap, OS_FSC_MEM_IDX2BIT(idx)); struct TagFscMemCtrl *currBlk = (struct TagFscMemCtrl *)addr; currBlk->next =&pool->freeListHeads[idx]; currBlk->prevSize = 0; currBlk->size = size; currBlk->prev =&pool->freeListHeads[idx]; pool->freeListHeads[idx].next = currBlk; pool->freeListHeads[idx].prev = currBlk; pool->startAddr = addr; pool->totalSize = size; pool->usage = 0; pool->peakUsage = 0; / / Set the end marker block struct TagFscMemCtrl *nextBlk = (struct TagFscMemCtrl *)(addr +size); nextBlk->next = OS_FSC_MEM_MAGIC_USED; nextBlk->size = 0; return OS_OK; } Memory allocation function jr_malloc void *jr_malloc(U32 size) { void *ptr = NULL; int poolIndex; / / -----Request for legality check----- if (size == 0) { OS_REPORT_ERROR(OS_ERRNO_MEM_ALLOC_SIZE_ZERO); return NULL; } / / Size limit checks can be added, etc. / / -----Atomic read and update rotation counter----- / / Get the current counter value and atomically increment it by 1 (mod 2). poolIndex = atomic_fetch_add(&g_jrAllocator.roundRobinCounter, 1) %2; / / -----Select memory pool based on counter value----- FscMemPool *selectedPool =&g_jrAllocator.pools[poolIndex]; / / ----- Allocate memory using the FSC algorithm from the selected pool ----- / / This calls the pool allocation function, which is a modified version of the original OsFscMemAllocInner and accepts the pool parameter. ptr = OsFscMemAllocInPool(selectedPool, size, OS_FSC_MEM_SIZE_ALIGN); / / -----Determine the allocation result----- if (ptr == NULL) { / / Allocation failed, proceeding to error handling goto error_handling; } / / -----Success, return pointer----- return ptr; error_handling: / / -----Error Handling----- / / Simplified example: Return NULL directly / / Another implementation: attempt to allocate in a different pool (not implemented here to avoid complexity) return NULL; } The memory release function jr_free U32 jr_free(void *ptr) { FscMemPool *pool = NULL; int poolIndex = -1; / / -----Request for legality check----- if (ptr == NULL) { return OS_ERRNO_MEM_FREE_ADDR_INVALID; } / / -----Determine the memory pool to which the pointer belongs----- / / Method A: Determine by address range (simple and requires no additional metadata) uintptr_t addr = (uintptr_t)ptr; for (int i = 0; i<2; i++) { FscMemPool *p =&g_jrAllocator.pools[i]; if (addr>= p->startAddr&&addr <p->startAddr + p->totalSize) { pool = p; poolIndex = i; break } } / / -----Check if the pool to which the pool belongs has been found----- if (pool == NULL) { / / Not found, proceeding to error handling goto error_handling; } / / -----Call the internal deallocation algorithm within the defined memory pool----- U32 ret = OsFscMemFreeInPool(pool, ptr); / / -----Determine the release result----- if (ret != OS_OK) { / / Release failed, entering error handling goto error_handling; } / / -----Release successful, returned OK----- return OS_OK; error_handling: / / -----Error Handling----- / / For example, logging or directly returning an error code. OS_REPORT_ERROR(OS_ERRNO_MEM_FREE_ADDR_INVALID); / / Or other appropriate errors return OS_ERRNO_MEM_FREE_ADDR_INVALID; } In summary, the allocator, memory allocation method, and memory release method of the present invention have the following beneficial effects: 1. Significantly reduces lock contention and improves concurrency performance: By dividing a single memory pool into multiple independent memory pools and distributing allocation requests to different independent memory pools in a round-robin fashion, lock contention, which was originally concentrated on a single global lock, is distributed across multiple independent memory pools. For example, in a scenario with two memory pools, the contention intensity can theoretically be reduced by half. Multiple threads can allocate resources simultaneously in different pools, greatly reducing the probability of tasks being blocked while waiting for locks, thereby significantly improving system throughput and concurrency performance in multi-core environments.

[0044] 2. Effectively suppressing performance jitter and enhancing system determinism: The reduction in lock contention directly improves the stability of allocation time. Since tasks no longer need to frequently spin-wait or block to compete for the same lock, the time overhead of each allocation operation becomes more consistent. The round-robin scheduling mechanism itself has deterministic O(1) overhead, avoiding time fluctuations caused by complex operations such as searching for free blocks. This makes the worst-case execution time (WCET) easier to predict and define, meeting the core requirements of real-time systems.

[0045] 3. Improve CPU cache locality: Distributing memory allocation across multiple pools helps isolate memory operations of different threads or tasks into different memory regions. The management data structures of each memory pool are more likely to be fixed in the local cache of one or a few CPU cores, reducing cache line bouncing caused by multiple cores sharing the same data structure, improving cache hit rate, and further reducing memory access latency.

[0046] 4. Improved system reliability and fault isolation: Multiple memory pools are logically relatively independent. If the management data structure of one memory pool is corrupted due to a program error, its impact may be limited to that pool and will not immediately spread to the entire heap memory, while other memory pools can still function normally. This fault isolation feature enhances the robustness of the system.

[0047] 5. Flexible design and strong adaptability: The number and size of memory pools, as well as the allocation algorithm within the pools, can be adjusted and optimized according to specific application scenarios. For example, a separate pool can be allocated to the most critical tasks with the highest real-time requirements, while other tasks share the remaining pool, thereby achieving a balance between performance and resource utilization.

[0048] The present invention also provides an electronic device, 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; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the allocator, the memory allocation method, and the memory release method described above.

[0049] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. The communication interface is used for communication between the aforementioned terminal and other devices.

[0050] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0051] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0052] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0053] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0054] The above are merely preferred embodiments of this application and are 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 protection scope of this application.

Claims

1. An allocator for optimizing memory dynamic allocation jitter performance, characterized in that, include: The heap memory partitioning module is used to divide the heap memory space available to the real-time operating system into several independent memory pools; The round-robin allocation scheduling module is used to maintain the round-robin counter. Based on the current value of the round-robin counter, it selects the target independent memory pool from several independent memory pools based on the memory allocation request, and records the index of the memory pool to be selected for the next allocation operation. The memory allocation execution module is used to call the allocation algorithm, perform memory allocation in the target independent memory pool, and return a memory pointer to the requester; The memory release module is used to return memory blocks to the free list based on memory release requests and by calling the release algorithm according to the memory pointer.

2. The dispenser according to claim 1, characterized in that, Also includes: The error handling module either migrates memory from other independent memory pools or returns an allocation failure message to the requester when there is insufficient space in a particular independent memory pool to satisfy the memory allocation request.

3. A memory allocation method for optimizing dynamic memory allocation jitter performance, characterized in that, Implemented using the distributor as described in claim 1 or 2, comprising: The available heap memory space in the real-time operating system is divided into several independent memory pools; Receive memory allocation requests; Based on the current rotation counter value, select the target independent memory pool from several independent memory pools; Within the target independent memory pool, the allocation algorithm is invoked to perform memory allocation operations; Return the allocated memory pointer to the requester.

4. The memory allocation method according to claim 3, characterized in that, When receiving a memory allocation request, if the request is determined to be invalid, an error value is returned to the requester.

5. The memory allocation method according to claim 3, characterized in that, It also includes the following steps: determine the return result of the memory allocation operation, and if the allocation result is a memory block of the required size in the memory allocation request, then obtain the memory pointer; If the allocation fails, an error value is returned to the requester; Alternatively, if this fails, return to the step of selecting a target independent memory pool from several independent memory pools based on the current rotation counter value, and perform memory reallocation.

6. A memory release method for optimizing the performance of dynamic memory allocation jitter, characterized in that, Implemented using the distributor as described in claim 1 or 2, comprising: Receive a memory release request that includes a memory pointer; Determine the independent memory pool to which the memory pointer belongs; The release algorithm is invoked within the respective independent memory pool to return the memory block pointed to by the memory pointer to the free data structure of the respective independent memory pool.

7. The memory release method according to claim 6, characterized in that, When receiving a memory release request that includes a memory pointer, if the memory release request is determined to be invalid, an error value is returned to the requester.

8. The memory release method according to claim 6, characterized in that, The step of determining the independent memory pool to which the memory pointer belongs includes: Traverse all independent memory pools and check if the memory pointer is located between the start and end addresses of a certain independent memory pool. If a memory pointer is found, record the corresponding memory pool index. Alternatively, if the identifier of the independent memory pool to which the memory pointer belongs has been stored during the memory allocation phase, the memory pool index is read from the metadata near the memory pointer.

9. The memory release method according to claim 6 or 8, characterized in that, If the independent memory pool to which the memory pointer belongs cannot be determined, error handling is performed.

10. An electronic device, characterized in that, It includes 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; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the allocator as described in claim 1 or 2, the memory allocation method as described in any one of claims 3 to 5, and the memory release method as described in any one of claims 6 to 9.

Images