A low-fragmentation secure memory management method of a real-time operating system

Abstract

The present application relates to the technical field of memory management, and particularly relates to a low-fragmentation safe memory management method of a real-time operating system. The method comprises the following steps: establishing a two-layer memory management structure of a dynamic memory allocator and an address space manager, and respectively managing byte-level memory blocks and page blocks; according to the type of a memory request, allocating a fixed-size object to a fixed-size partition, and allocating other memory requests to a general heap; according to the block size, establishing an AVL size tree for the idle memory blocks in the general heap, and searching for the smallest idle block greater than or equal to the request size for allocation; for a memory release request, locating adjacent memory blocks according to the boundary markers of the memory blocks, and merging the adjacent idle blocks. Through the two-layer memory management structure, the AVL idle block index, the adjacent block merging, the boundary protection check and the page alignment expansion mechanism, the present application realizes the dynamic memory management with low fragmentation, high safety and high reliability in the real-time operating system.

Description

Technical Field

[0001] This invention relates to the field of memory management technology, and in particular to a low-fragmentation, secure memory management method for a real-time operating system. Background Technology

[0002] Real-time operating systems (RTOSs) are widely used in aerospace, industrial control, automotive electronics, and medical equipment, placing high demands on the real-time performance, determinism, and reliability of memory management. Existing RTOS memory management methods mainly include fixed partition management, dynamic linked list management, TLSF management, and a hybrid page-based TLSF management scheme. Among these, fixed partition management suffers from poor memory request adaptability and severe internal fragmentation; dynamic linked list management, while supporting flexible allocation, suffers from low lookup efficiency and the easy accumulation of external fragmentation; and while the hybrid TLSF and page-based TLSF management schemes improve allocation efficiency, they still struggle to effectively eliminate small free blocks generated during long-term operation, and the expansion process can easily lead to wasted address space.

[0003] Therefore, existing real-time operating system memory management technologies struggle to simultaneously address the requirements of real-time memory allocation, fragmentation suppression, and memory security, easily leading to a decline in long-term system stability. To address this, a low-fragmentation, secure memory management method for real-time operating systems is needed to reduce memory fragmentation, improve memory utilization, and enhance the security and reliability of dynamic memory management. Summary of the Invention

[0004] Therefore, it is necessary to provide a low-fragmentation secure memory management method for a real-time operating system to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a low-fragmentation, secure memory management method for a real-time operating system is provided, the method comprising the following steps: Step S1: Establish a two-layer memory management structure of dynamic memory allocator and address space manager, and manage byte-level memory blocks and page blocks respectively; Step S2: Based on the type of memory request, allocate fixed-size objects to fixed-size partitions and allocate other memory requests to the general heap; build an AVL size tree for free memory blocks in the general heap according to block size, and retrieve the smallest free block that is greater than or equal to the request size for allocation; Step S3: For memory release requests, locate adjacent memory blocks based on the boundary markers of the memory blocks, and merge adjacent free blocks; Step S4: Configure boundary protection information in the memory block control header of the general heap, and verify the boundary protection information based on the memory allocation process and the memory release process to detect memory out-of-bounds access; Step S5: When the existing free memory cannot meet the memory allocation request, request contiguous memory from the address space manager through the automatic growth callback function, and determine the expansion alignment size according to the page size supported by the MMU.

[0006] The beneficial effects of this invention are as follows: I. By establishing a two-layer memory management structure combining a dynamic memory allocator and an address space manager, hierarchical management of byte-level and page-level memory blocks is achieved. In the dynamic memory allocation layer, a combination of fixed-size partitions and a general-purpose heap is used for different types of memory requests. An AVL tree based on block size indexes is used to quickly match the optimal free block, avoiding the efficiency reduction caused by traditional sequential traversal and the long-term accumulation of small free spaces. Simultaneously, the address space manager manages page blocks independently, decoupling the memory expansion process from the application-layer allocation process, thus improving the stability and scalability of dynamic memory management in real-time operating systems. Second, by locating adjacent memory blocks based on boundary markers during memory release and performing adjacency detection and merging on byte-level memory blocks and page-level page blocks respectively, proactive reorganization of free space is achieved. Compared to the traditional method that relies solely on free list management, this solution can promptly eliminate fragmented space in contiguous regions during the release phase, improving the ability to satisfy large-capacity contiguous memory requests. Simultaneously, by configuring boundary protection information in the general heap memory block control header and performing protection checks during the release phase, data corruption caused by out-of-bounds writes can be detected in a timely manner, preventing abnormal memory access from further affecting the execution of real-time tasks and improving the security of memory usage in the real-time operating system. Third, a collaborative expansion mechanism between the dynamic memory allocator and the address space manager is implemented through an automatic growth callback function. This, combined with page size information supported by the MMU, determines the expansion alignment size, ensuring that the newly added memory region meets hardware page table mapping requirements. During the expansion process, page size multiples are checked at each level, and the final expansion unit is padded to maintain a continuous address layout and page boundary alignment, reducing the probability of fragmentation during subsequent page mapping and memory reclamation. Therefore, while ensuring flexible dynamic memory expansion, memory utilization, address space continuity, and long-term system reliability are improved. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a low-fragmentation, secure memory management method for a real-time operating system; Figure 2 for Figure 1 A detailed flowchart illustrating the implementation steps of step S3. Figure 3 This is a schematic diagram of the core structure of a memory management system according to one embodiment; Figure 4 This is a schematic diagram of the prior art heap memory fragmentation state according to an embodiment; Figure 5 This is a schematic diagram of the heap memory state after adopting the present invention in one embodiment; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0008] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0009] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0010] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0011] To achieve the above objectives, please refer to Figures 1 to 5 A low-fragmentation, secure memory management method for a real-time operating system, the method comprising the following steps: Step S1: Establish a two-layer memory management structure of dynamic memory allocator and address space manager, and manage byte-level memory blocks and page blocks respectively; Step S2: Based on the type of memory request, allocate fixed-size objects to fixed-size partitions and allocate other memory requests to the general heap; build an AVL size tree for free memory blocks in the general heap according to block size, and retrieve the smallest free block that is greater than or equal to the request size for allocation; Step S3: For memory release requests, locate adjacent memory blocks based on the boundary markers of the memory blocks, and merge adjacent free blocks; Step S4: Configure boundary protection information in the memory block control header of the general heap, and verify the boundary protection information based on the memory allocation process and the memory release process to detect memory out-of-bounds access; Step S5: When the existing free memory cannot meet the memory allocation request, request contiguous memory from the address space manager through the automatic growth callback function, and determine the expansion alignment size according to the page size supported by the MMU.

[0012] In some embodiments, a dynamic memory allocator and an address space manager are established within the real-time operating system. The dynamic memory allocator is located at the upper layer and is used to receive memory allocation and deallocation requests from applications and manage the heap space at the byte level. The address space manager is located at the lower layer and is used to maintain the virtual address space and physical page frames and provide contiguous page space at the page level.

[0013] In the dynamic memory allocator, a partition description structure is established for each memory partition. The partition description structure is configured with the root node of the AVL size tree, the memory segment linked list, and the auto-growing callback function pointer. At the same time, a control header is set at the beginning of each memory block. The size of the previous memory block is recorded through the prev_size field in the control header, the size of the current memory block is recorded through the size field, and the low-order bits of the size field are used to store the free status identifier of the previous block to form a byte-level boundary marker structure.

[0014] In the address space manager, a page pool description structure is established, along with an address tree and a size tree. The address tree records the starting position, number of consecutive pages, and allocation status of all page blocks according to page number. The size tree records free page blocks according to the number of consecutive free pages, and free page blocks of the same size are linked together using a linked list, thus achieving page-level memory management. The dynamic memory allocator and the address space manager establish a calling relationship through an auto-growth callback function. When the dynamic memory allocator cannot satisfy a byte-level allocation request, the auto-growth callback function calls the address space manager to request new consecutive pages and converts the requested page space into heap space manageable by the dynamic memory allocator.

[0015] When an application initiates a memory allocation request, the size characteristics of the requested object are identified. If the requested object is a fixed-size object that is repeatedly allocated and freed, the request is directed to the fixed-size partition allocation process. Specifically, a fixed-size partition is matched to the object size, free blocks in the fixed partition are removed from the free list, and the status of free blocks in that partition is updated. If the requested object is not a fixed-size object, the request is sent to the dynamic memory allocator for allocation by the general-purpose heap.

[0016] For the general heap allocation process, the target allocation size corresponding to the memory request is first obtained, and a search is performed in the AVL size tree using the free memory block size as the index key. The nodes in the AVL size tree are sorted according to the free block size, and each node is associated with a linked list of free memory blocks of the same size. When an allocation request is received, the first node with a size greater than or equal to the requested size is obtained by searching the successor node of the AVL tree, and a free block is selected from the free block linked list corresponding to that node as the best-fit allocation block.

[0017] After obtaining the best-fit allocation block, remove the free block from the corresponding linked list of the AVL size tree. If there are other free blocks in the size node, only the current free block is removed. If the current free block is the only free block in the size node, the corresponding AVL node is deleted simultaneously. Then, calculate the difference between the current free block size and the requested size.

[0018] When the difference exceeds the preset minimum partitioning threshold, the current free block is divided into allocated blocks and remaining free blocks. The portion that meets the requested size is set as an allocated block, and the remaining portion is reconstructed into a new free block. The new free block is then reinserted into the AVL size tree according to its size. When the difference is less than or equal to the minimum partitioning threshold, no further splitting is performed, and the entire free block is directly allocated to the requesting object to avoid creating unusable small fragments. After allocation, the corresponding memory partition identifier, block size information, and boundary protection information are written to the allocated block control header, and the address of the data region following the control header is returned to the application, allowing the application to obtain usable contiguous memory space.

[0019] When an application initiates a memory release request, it offsets the memory block control header length forward from the address of the memory to be released to obtain the control header address of the corresponding memory block, and reads the size field, prev_size field, and the previous block free status flag from the control header. The prev_size field records the size of the physically adjacent preceding memory block, the size field records the current memory block size, and the previous block free status flag in the size field is used to determine the status of adjacent blocks.

[0020] Subsequently, the address is calculated based on the prev_size field in the current memory block control header to obtain the control header address of the previous physical adjacent memory block. When the previous memory block is detected to be in a free state, the previous free block is removed from the AVL size tree, and the starting address of the current free block is adjusted to the starting position of the previous free block. At the same time, the sizes of the two memory spaces are added to merge the previous free block and the current free block to form a new contiguous free block.

[0021] The location of the next physically adjacent memory block is calculated based on the size of the merged memory block. The control header address of the next block is obtained by adding the current block address to the current block size, and the free status flag in the control header of the next block is read. When the next block is in a free state, the next free block is removed from the AVL size tree, and the space of the next block is merged into the current free block, thereby completing the continuous merging of adjacent free blocks.

[0022] After merging adjacent free blocks, the size information of the merged free block is recalculated, and the size field in the corresponding control header, the prev_size field in the control header of the subsequent memory block, and the free status flag of the previous block are updated. Then, the free block is re-inserted into the AVL size tree using the size of the merged free block as an index, so that subsequent memory requests can retrieve the contiguous free region.

[0023] When allocating memory on the general-purpose heap, a boundary protection region is configured simultaneously with the generation of the allocated memory block control header. Specifically, a protection field is set in the memory block control header to store a fixed checksum; concurrently, a protection space is set between the control header and the user data area, or at the end of the user data area, and a corresponding boundary protection identifier is written therein, forming a memory block integrity detection region. After memory allocation is complete, the boundary protection information in the allocated memory block control header is associated with the current memory block, and the current memory block size, its partition identifier, and the protection checksum are recorded. This allows the subsequent release process to perform integrity checks on the memory block based on the control header information.

[0024] When an application requests to release memory, it first locates the control header of the corresponding memory block based on the release address and reads the boundary protection information in the control header. Then, it compares the read protection check value with a pre-written fixed check value. If they match, it is determined that the current memory block control structure and boundary region are not abnormal, and the memory release and adjacent block merging process continues. If they do not match, it is determined that the memory block has experienced out-of-bounds write behavior, triggering memory error detection processing. Specifically, for 32-bit platforms, a fixed magic number is written to the headGuard field in the control header, and the control header corruption caused by buffer underflow is determined by detecting whether this field has been modified. For 64-bit platforms, a protected region is independently set between the control header and the user data area, and out-of-bounds detection is performed through this independent protected space.

[0025] After receiving a memory allocation request, the dynamic memory allocator searches for a free memory block in the AVL size tree of the general-purpose heap, using the requested size as the search criterion. If no free block larger than or equal to the requested size is found by searching through the successor nodes of the AVL size tree, it is determined that the current general-purpose heap space cannot satisfy the allocation request, and the heap expansion process begins. Subsequently, the dynamic memory allocator calls the internal growth function `mem_part_grow`, calculates the required expansion space based on the current allocation size, memory segment management overhead, and the overhead of adding a new AVL node, and passes the calculation result as an input parameter to the automatic growth callback function. The automatic growth callback function is pre-registered in the dynamic memory allocator and is used to connect the dynamic memory allocator and the address space manager.

[0026] After receiving an expansion request, the automatic growth callback function first obtains the page size supported by the current system MMU and rounds up the number of bytes requested for expansion to an integer multiple of the page size. When the system enables the page optimization function, it further calculates the optimized page alignment size based on the large page mapping capability supported by the MMU, so that the expansion area meets the continuous page mapping requirements.

[0027] Then, the auto-growth callback function calls the page-level memory allocation interface in the address space manager. Based on the determined expansion size, it searches for contiguous free page blocks in the page pool that meet the conditions. It retrieves the required contiguous page region through a page-level size tree search and allocates the corresponding virtual address space and physical page frames, while simultaneously establishing the MMU mapping relationship between the virtual address and the physical page frame. After completing the page allocation, the address space manager returns the actual allocated contiguous memory size to the auto-growth callback function, which then writes the actual expansion size back to the dynamic memory allocator. Subsequently, the dynamic memory allocator creates a new memory segment based on the returned contiguous memory address, adds the memory segment to the memory segment linked list of the current memory partition, and initializes the corresponding memory block control header, boundary markers, and free block structure.

[0028] Finally, the newly generated free memory blocks are inserted into the AVL size tree according to the block size, and the best fit search process corresponding to the current memory request is re-executed to obtain memory blocks that meet the requested size from the newly added expansion space, thus completing the memory allocation after this dynamic expansion.

[0029] In another embodiment, reference can be made to Figure 3 , Figure 3This diagram illustrates the core structure of the memory management system in an embodiment of the present invention. The memory management system employs a two-layer management structure combining a dynamic memory allocator and an address space manager. The dynamic memory allocator, located at the upper layer, primarily addresses the memory allocation and deallocation needs of applications, managing byte-level memory blocks in the heap space and handling different types of memory requests through fixed-size partitions, a general-purpose heap, and a free block size index structure. The address space manager, located at the lower layer, primarily manages contiguous page blocks, virtual address space, and physical page frames. When the existing free space in the upper-layer dynamic memory allocator cannot meet the memory allocation needs, a new contiguous page space can be requested from the address space manager through an auto-growth callback function. The obtained page space is then converted into heap memory space that can be further managed by the dynamic memory allocator, thus forming a collaborative mechanism between byte-level memory management and page-level address space management.

[0030] and Figure 4 This diagram illustrates the fragmentation state of heap memory in the prior art. In traditional dynamic memory allocation, after multiple allocations and releases of memory blocks of different sizes, allocated and free memory blocks tend to alternate in the address space, dividing what was originally a contiguous memory region into multiple smaller and more dispersed free memory blocks. At this point, although there may still be a large total remaining memory capacity in the heap space, the isolation between free spaces by allocated memory blocks makes it difficult to form a contiguous free region to meet the needs of large memory requests. This can easily lead to a situation where there is sufficient total remaining space but contiguous memory allocation cannot be completed, affecting the actual utilization efficiency of the heap space. Figure 5 This diagram illustrates the heap memory state after employing the memory management method of this invention. During memory block release, the adjacent memory blocks before and after the memory block to be released are located based on the boundary marker information in the memory block control header, and memory blocks that are free and physically contiguous are merged. By recombining multiple adjacent small-sized free memory blocks into a larger contiguous free memory region, and then re-incorporating them into the free block management structure according to the size of the merged memory block, the number of scattered small free memory blocks in the heap space can be reduced, making the distribution of free memory space more concentrated. Therefore, compared to... Figure 4 As shown in the fragmented state, the present invention can actively organize the continuous free space during the memory release phase, improve the ability to satisfy large memory requests, and reduce the possibility of continuous accumulation of heap memory fragments during long-term operation.

[0031] Preferably, step S1 includes: Establish a dynamic memory allocator at the upper level, enabling the dynamic memory allocator to receive memory allocation and memory deallocation requests from the application, and using byte-level memory blocks as the basic management object; In the dynamic memory allocator, an AVL size tree is built with the size of the free memory block as the index, and the current memory block size and the previous memory block size are recorded in the control header of each memory block to form a byte-level memory block size index and adjacent positioning structure. An address space manager is established below the dynamic memory allocator, with page blocks as the basic management object. An address tree arranged according to page addresses and a size tree arranged according to the size of free page blocks are established to manage the address information and free capacity of page blocks. By connecting the dynamic memory allocator and the address space manager through an auto-growth callback function, the dynamic memory allocator can initiate a page-level contiguous memory request to the address space manager when the existing byte-level free memory cannot meet the allocation request.

[0032] In some embodiments, a dynamic memory allocator is created in the real-time operating system kernel and configured as the access interface between the application and the underlying memory resources. When the application calls the memory request interface, the dynamic memory allocator receives the request parameters and searches for available memory blocks in the currently managed heap space according to the requested space size. When the application releases the requested memory, the dynamic memory allocator receives the release address and performs the corresponding memory block reclamation process. The dynamic memory allocator uses a single byte-level memory block as the management unit and uniformly maintains the free areas, allocated areas, and memory block states in the heap space.

[0033] An AVL size tree is created inside the dynamic memory allocator, and the size of the free memory block is used as the sorting key value of the AVL size tree. All free memory blocks are mounted to the corresponding nodes according to their size relationship. When there are multiple free memory blocks of the same size, the free blocks of the same size are associated with the free list corresponding to the node of the same size.

[0034] Meanwhile, a memory block control header is set at the beginning of each memory block. The control header is configured with a prev_size field and a size field. The prev_size field is used to record the size of the physical adjacent memory block before it, and the size field is used to record the size of the current memory block. The address of the previous memory block can be calculated by combining the current memory block address with the prev_size field, and the address of the next memory block can be calculated by combining the current address with the size field, thus establishing an adjacent memory block location mechanism that does not require an additional address index structure.

[0035] An address space manager is built below the dynamic memory allocator, and pages are used as the granularity for underlying memory resource management. The address space manager creates a page pool description structure, and builds an address tree and a size tree in the page pool. The address tree uses the starting page number of the page block as an index to sort and manage all page blocks, including allocated page blocks and free page blocks. The size tree uses the number of consecutive free pages as an index to record only page blocks that are in a free state.

[0036] When a page block is created, a page block address node is established for each consecutive page region, and the starting page number, the number of consecutive pages, and the current allocation status are recorded in the address node. Meanwhile, free page blocks are also attached to the size tree so that consecutive free page blocks that meet the conditions can be quickly found based on the number of requested pages.

[0037] An auto-growth callback function is registered in the dynamic memory allocator, and its pointer is stored in the memory partition description structure. When the dynamic memory allocator receives a memory allocation request, it first searches for a free memory block that meets the requested size in its managed AVL size tree; if no byte-level free block meets the conditions, the auto-growth callback function is invoked.

[0038] The auto-growth callback function sends a page expansion request to the address space manager based on the currently missing memory capacity. The address space manager then searches for contiguous free pages according to the page management structure and returns the corresponding contiguous address space. Upon receiving the newly added memory region, the dynamic memory allocator adds the region to the current heap space, initializes the corresponding memory block control information, and re-executes the byte-level memory allocation process.

[0039] As an example of the present invention, reference is made to Figure 2 As shown, step S3 in this example includes: Step S31: Receive a byte-level memory release request, obtain the corresponding memory block control header based on the memory address to be released, and read the size information of the current memory block and the free flag of the previous memory block; Step S32: Calculate the address of the previous memory block based on the boundary marker of the current memory block, and determine the free state of the previous memory block according to the free flag of the previous memory block; when the previous memory block is in a free state, remove the previous memory block from the free block size tree, and merge the current memory block with the previous memory block. Step S33: Calculate the address of the next memory block based on the size of the merged memory block, and read the free flag of the previous memory block of the next memory block; when the next memory block indicates that the current merged block is in a free state, remove the next memory block from the free block size tree, and merge the next memory block with the current merged block; Step S34: Reinsert the memory block after merging adjacent blocks into the free block size tree according to the size of the merged block, and update the previous free block flag and the previous block size information of the next memory block.

[0040] In some embodiments, when an application calls the memory release interface, the dynamic memory allocator receives the corresponding release address and, based on the release address, shifts forward by the length of the memory block control header to locate the control header position corresponding to the memory block to be released.

[0041] Subsequently, the `size` field, `prev_size` field, and the previous memory block free flag in the control header are read. The `size` field records the size of the current memory block, the `prev_size` field records the size of the physically adjacent preceding memory block, and the previous memory block free flag indicates whether the adjacent memory blocks before the current memory block are free. Using this control header information, the dynamic memory allocator can obtain the boundary information of the currently released block and the status of adjacent memory blocks without traversing the entire free block management structure.

[0042] The location of the previous memory block is calculated based on the `prev_size` field in the current memory block control header. This is done by subtracting the size of the previous memory block from the current memory block's starting address to obtain the control header address of the previous memory block. The free flag of the previous memory block recorded in the current memory block control header is read. If this flag indicates the previous memory block is allocated, the current free block remains independent. If the flag indicates the previous memory block is free, it means the current free block and the previous memory block are physically contiguous. At this point, based on the size information of the previous memory block, the corresponding free node is located in the free block size tree, and the previous free memory block is deleted from the free block size tree to avoid duplicate management of the same free region during the merging process. Then, the previous memory block and the current free memory block are merged, the sizes of the two memory spaces are added together, and the merged previous memory block is used as the new free memory block. Simultaneously, the block size information in the corresponding control header is updated to describe the merged contiguous free region.

[0043] Using the currently merged memory block as a baseline, the address of the next physically adjacent memory block is calculated based on the starting address and size information of the current merged block. The free flag of the previous memory block in the control header of the next memory block is read to determine the state of the previous block corresponding to the current merged block. If the free flag in the next memory block indicates that the current merged block is in an allocated state, then the next memory block cannot participate in the merge, and the state of the current merged block remains unchanged. If the flag indicates that the current merged block is in a free state, then the next memory block and the current merged block are contiguous and both are free regions. In this case, the next memory block is removed from the free block size tree, and its space is merged into the current merged block. The total size of the merged memory block is recalculated, and the position of the merged block control header and boundary marker information are adjusted to form a single contiguous free region from multiple consecutive free blocks.

[0044] After merging adjacent memory blocks, the size field in the current memory block control header is first updated according to the size of the merged continuous free region, and the corresponding boundary marker information is updated synchronously.

[0045] Subsequently, using the merged memory block size as the index value, the contiguous free block is re-inserted into the free block size tree; when a free block of the same size exists, the memory block is attached to the free list of the corresponding size node; when no corresponding node exists, a new size node is created and an association is established.

[0046] After the free block is re-registered, the next memory block is located based on the end address of the merged memory block, and the prev_size field in the control header of the next memory block is modified to record the new size of the merged block. At the same time, the previous free block flag in the next memory block is updated so that subsequent release operations can quickly determine the adjacent free status based on the boundary marker.

[0047] Preferably, after step S34, the method further includes: For the received page-level memory release request, use the starting page number of the page block to be released as the key to perform a predecessor lookup in the address tree to obtain the adjacent predecessor page block whose page number is less than the starting page number; Determine if the predecessor page block is in an idle state, and determine if the end page number of the predecessor page block is consecutive to the start page number of the page block to be released; if the consecutiveness condition is met, remove the predecessor page block from the address tree and size tree, and merge it with the page block to be released; Using the end page number of the merged page block as the key, perform a successor search in the address tree to obtain the adjacent successor page block whose page number is greater than the end page number; Determine if the successor page block is idle, and determine if the starting page number of the successor page block is consecutive to the ending page number of the merged page block; if the consecutiveness condition is met, remove the successor page block from the address tree and size tree, and merge it with the merged page block; After merging adjacent page blocks, the page blocks are re-inserted into the address tree according to the starting page number, and then inserted into the size tree according to the number of merged pages.

[0048] In some embodiments, when the address space manager receives a page-level memory release request, it first obtains the starting page number and the number of consecutive pages corresponding to the page block to be released, and uses the starting page number as the address tree retrieval key. Subsequently, a predecessor node lookup operation is performed in the address tree, that is, the node with a page number less than the starting page number of the page block to be released and the closest node is found, and the page block corresponding to that node is taken as the adjacent predecessor page block. If no predecessor page block meeting the conditions is found, it indicates that there is no mergeable page region before the page block to be released, and the subsequent successor page block detection process is directly initiated. The address tree is sorted and stored according to the starting address of the page block, and the size relationship between tree nodes allows for quick location of physically adjacent page blocks without traversing all page block information.

[0049] The allocation status information of the corresponding node of the predecessor page block is obtained to determine whether the predecessor page block is currently in an idle state. If the predecessor page block is in an allocated state, the merge operation is not performed. When the predecessor page block is in an idle state, its end page number is calculated based on the start page number and the number of consecutive pages recorded in the predecessor page block, and it is determined whether the end page number and the start page number of the page block to be released satisfy the page number continuity relationship. When the continuity condition is met, it means that the predecessor page block and the page block to be released are contiguous in the physical address space. At this time, the corresponding node is located in the address tree based on the page number information of the predecessor page block, and the predecessor page block node is removed. At the same time, the corresponding size node is located in the size tree based on the number of free pages of the predecessor page block, and the association between the page block and the size tree is removed. Subsequently, the predecessor page block and the page block to be released are merged, the number of consecutive pages of the two page blocks is accumulated, and the merged predecessor page block is used as the new contiguous free page block, updating its start page number and page number information.

[0050] After merging the predecessor page blocks, the end page number of the merged page block is calculated based on the starting page number and the number of consecutive pages, and this end page number is used as the address tree search condition. Subsequently, a successor node lookup operation is performed in the address tree to obtain the node with a page number greater than the current end page number and the closest proximity, and the page block corresponding to this node is identified as the adjacent successor page block. Through the successor lookup in the address tree, the physically adjacent page region after the current merged page block can be quickly located, providing a basis for subsequent determinations on whether merging can continue.

[0051] The status information of the corresponding node of the successor page block is read to determine whether the successor page block is a free page block. If the successor page block is in an allocated state, the current merged page block status remains unchanged. If the successor page block is in a free state, the starting page number of the successor page block is further calculated, and it is determined whether this starting page number is consecutive to the ending page number of the current merged page block. If the consecutiveness condition is met, it means that the successor page block and the current merged page block belong to a consecutive free page region. At this time, the corresponding node of the successor page block is deleted from the address tree and simultaneously removed from the corresponding free page block linked list of the large and small trees. Subsequently, the successor page block is merged into the current merged page block, the number of consecutive pages in the two page blocks is accumulated to form a new consecutive free page block, and the range information of the merged page block is updated.

[0052] After merging the predecessor and successor page blocks, the information of the final merged contiguous free page block is obtained, including the starting page number, ending page number, and number of consecutive pages. Then, using the starting page number of the merged page block as the index key, the page block is re-inserted into the address tree, enabling the address tree to maintain the current page space distribution according to page address order. Simultaneously, using the number of consecutive pages after merging as the index key, the free page block is inserted into the size tree; if a free page block with the same number of pages exists in the size tree, the current page block is added to the free list of the corresponding node; otherwise, a new size node is created.

[0053] Preferably, step S4 includes the following steps: Step S41: When allocating memory blocks in the general heap, configure boundary protection information in the memory block control header and set a corresponding protection area between the memory block and the user data area; Step S42: Determine the user data area and corresponding protection area of ​​the memory block according to the memory allocation request, and establish a correspondence between the boundary protection information and the memory block; Step S43: Upon receiving a memory release request, obtain the corresponding memory block control header based on the address of the memory to be released, and read the boundary protection information corresponding to the memory block; Step S44: Verify the read boundary protection information with the preset protection information. If the verification is inconsistent, it is determined that there is an out-of-bounds write to the memory block, and the corresponding memory release process is terminated. If the verification is consistent, the memory block is released and adjacent free blocks are merged.

[0054] In some embodiments, after the dynamic memory allocator determines the target free memory block based on the memory request, the control header of the memory block to be allocated is initialized during the memory block partitioning process. First, a boundary protection field is added to the memory block control header to store the protection verification information corresponding to the current memory block. Simultaneously, a protection region is set after the memory block control header, positioned between the memory block management information and the data area actually accessed by the user. After the protection region partitioning is completed, preset protection information is written into the corresponding protection field, and this protection information is associated with the starting address and block size information of the current memory block. This allows for subsequent boundary integrity verification of the memory block after locating it based on the release address. The boundary protection information is recorded using a fixed verification identifier. When the memory block control structure or adjacent areas change due to abnormal writes, changes in the protection information can be used to determine if out-of-bounds access has occurred.

[0055] Upon receiving a memory allocation request, the effective data length of the current memory block is determined based on the requested size, and the starting address of the user data region is calculated based on the space occupied by the memory block control header. Subsequently, the user data region and a corresponding protection region are partitioned after the memory block control header. The user data region is used for data storage returned to the application, while the protection region stores boundary detection information. After region partitioning, the block identifier, block size information, and boundary protection information in the current memory block control header are bound together, ensuring that each allocated memory block has independent corresponding protection verification information. When the application subsequently accesses or releases the memory block, it can reverse-engineer the corresponding control header based on the memory address and obtain the boundary protection information corresponding to that memory block.

[0056] When an application calls the memory release interface, the dynamic memory allocator receives the address of the memory to be released and, based on the offset relationship between the release address and the memory block control header, performs address backtracking on the release address to obtain the position of the corresponding memory block control header. Subsequently, it reads the block size information, memory status information, and boundary protection information from the memory block control header and determines the location of the protected region corresponding to the memory block to be released based on the information recorded in the control header. Further, it obtains the corresponding protection check value from the boundary protection field in the current memory block control header and uses this check value as the basis for checking the integrity of the current memory block, performing out-of-bounds detection before performing the release operation.

[0057] The boundary protection information read in step S43 is compared with the pre-configured protection information in the dynamic memory allocator. When the read boundary protection information matches the preset protection information, it indicates that the current memory block control header and protected area have not been abnormally modified. Therefore, it is determined that the current memory block does not have out-of-bounds write behavior, and the normal release process continues. Specifically, the current memory block status is updated to free state, and adjacent memory blocks are found according to the memory block boundary markers. When adjacent memory blocks are in a free state, they are removed from the free block management structure, and a continuous free block merging operation is performed. When the read boundary protection information does not match the preset protection information, it indicates that the content of the protected area has changed, and it is determined that the current memory block may have boundary corruption caused by out-of-bounds write. At this time, the current memory release process is terminated to prevent abnormal memory blocks from entering the free block management structure and further damaging the heap space.

[0058] Preferably, step S5 includes the following steps: Step S51: When the dynamic memory allocator cannot obtain a memory block from the existing free block to satisfy the memory allocation request, the automatic growth callback function is triggered, and an expansion request containing the requested memory size is sent to the address space manager. Step S52: The address space manager receives the expansion request, obtains the set of page sizes supported by the current platform through the MMU hardware interface, and determines the candidate page size that is greater than or equal to the requested memory size from the set of page sizes; Step S53: Determine the expansion alignment size based on the multiple relationship between the candidate page size and the larger page size, and adjust the requested memory size upward to an integer multiple of the expansion alignment size; Step S54: Based on the expansion alignment size, allocate a continuous range of virtual addresses in the virtual page pool and allocate corresponding continuous physical page frames in the physical page frame pool, wherein the starting address that matches the expansion alignment size is selected first. Step S55: Establish page table mapping between virtual address and physical address based on the expanded alignment size, and add the expanded memory block with the completed mapping as a new memory segment to the dynamic memory allocator to form a free memory block that can be used for subsequent memory allocation.

[0059] In some embodiments, when the dynamic memory allocator receives a memory allocation request, it first performs a search operation in the free block size tree based on the requested memory size to obtain a free memory block that meets the request conditions. If there is no free block in the free block size tree that is greater than or equal to the requested size, it is determined that the current remaining space in the general-purpose heap cannot meet the allocation requirements. Subsequently, the dynamic memory allocator calls a pre-registered auto-growth callback function and encapsulates the current memory request size, the required expansion space size, and the current heap space status information into an expansion request and sends it to the address space manager. The auto-growth callback function serves as the connection interface between the dynamic memory allocator and the address space manager, converting byte-level memory shortage events into page-level space allocation requests, enabling the underlying address space manager to perform continuous memory expansion based on the page resource status.

[0060] Upon receiving an expansion request, the Address Space Manager first reads the target expansion size in the request and obtains the page size information supported by the current processor platform through the MMU hardware configuration interface. The MMU hardware interface returns multiple page size parameters usable by the current platform, forming a page size set. The Address Space Manager matches the page sizes in this set against the requested space size in the expansion request. Subsequently, the page sizes are compared in ascending order to select those that can cover the currently requested memory size. The first page size that meets the condition of being "greater than or equal to the requested memory size" is designated as a candidate page size, serving as the basis for subsequent expansion alignment calculations.

[0061] After determining the candidate page size, the address space manager further obtains the larger page size supported by the MMU and calculates the integer multiple relationship between the candidate page size and the larger page size. When the candidate page size can be mapped to the larger page size in an integer multiple manner, the corresponding larger page size is used as the expansion alignment size to improve page utilization efficiency in subsequent virtual address mapping processes; when no larger matching page size exists, the candidate page size is directly used as the expansion alignment size. Subsequently, based on the determined expansion alignment size, the original requested memory size is rounded up, i.e., the expansion size is calculated to satisfy: expansion size = expansion alignment size × integer multiple of the actual expansion space, so that the finally requested page space can be aligned according to the MMU page boundaries.

[0062] Based on the calculated expansion size, the Address Space Manager searches the virtual page pool for free virtual address regions that meet the requirement for the number of consecutive pages. Specifically, it uses the number of requested pages as the search criterion to search for consecutive free virtual page blocks in the page management structure. When multiple virtual page regions meet the criteria, the region with the starting address that meets the expansion alignment size requirement is selected first, so that the corresponding page size can be directly used for mapping in subsequent page table mapping processes. After determining the virtual address range, the Address Space Manager further searches the physical page frame pool for the corresponding number of consecutive free physical page frames and establishes a one-to-one correspondence between virtual pages and physical page frames. When a large contiguous physical space that meets the expansion alignment requirement exists in the physical page frame pool, this region is selected first as the expansion space to reduce the number of page mappings and reduce address space fragmentation.

[0063] After completing the virtual address range and physical page frame allocation, the address space manager generates corresponding page table entries based on the determined expansion alignment size, mapping contiguous virtual addresses to contiguous physical page frames. Subsequently, the mapped virtual address region and corresponding physical page frame information are recorded in the page management structure, and the page state in the address tree and size tree is updated, transforming the newly added page region from the address space level into usable memory resources. After completing the expansion, the address space manager returns the starting address of the newly added contiguous memory region and the actual expansion size to the dynamic memory allocator. Upon receiving the new region, the dynamic memory allocator adds it as a new memory segment to the general heap management structure and initializes the corresponding memory block control header, boundary markers, and free block information. The newly formed free memory blocks are inserted into the free block size tree according to their block size, enabling subsequent memory allocation requests to be directly retrieved and allocated from the expanded general heap. Through this method, dynamic expansion to the page-level address space is achieved when byte-level heap space is insufficient, and the continuity and alignment of the expanded region are guaranteed by MMU page size constraints.

[0064] Preferably, step S53 includes: The set of page sizes is arranged in ascending order of page size, and the smallest page size that is greater than or equal to the requested memory size is determined as the candidate page size; Get the size of the next page that is larger than the candidate page size, and determine whether the size of the next page is an integer multiple of the candidate page size; When the size of the next page is an integer multiple of the candidate page size, the size of the next page is used as the expansion alignment reference, and it is further determined whether the larger page size corresponding to the expansion alignment reference satisfies the integer multiple relationship, so as to determine the expansion alignment size step by step. When there is no larger page size that satisfies the integer multiple relationship, the currently determined expansion alignment reference is used as the expansion alignment size; when the candidate page size does not satisfy the integer multiple relationship with the larger page size, the candidate page size is directly used as the expansion alignment size. The alignment size is calculated to cover the entire alignment range that can cover the requested memory size, and the remaining space beyond the requested memory size is used as the edge extension space of the expanded memory segment, so that the size of the expanded memory segment is kept as an integer multiple of the alignment size.

[0065] In some embodiments, the address space manager obtains a set of page sizes returned by the MMU hardware interface and sorts them in ascending order of page capacity to form an increasing sequence of page sizes. For example, when the set of page sizes contains multiple different levels of page capacity, smaller page sizes are arranged first, followed by larger page sizes, so that subsequent matching can be performed level by level according to the granularity of page mapping.

[0066] The requested memory size sent by the dynamic memory allocator is used as a matching criterion. The page sizes are compared sequentially from the sorted sequence to find the first page size greater than or equal to the requested memory size, which is then designated as a candidate page size. If the requested memory size is less than the current minimum page size, it is directly selected as the candidate page size; if the requested memory size exceeds a certain page size, the matching continues towards larger page sizes. After determining the candidate page size, the next page size following the candidate page size is obtained from the page size sequence, and the ratio between the next page size and the candidate page size is calculated.

[0067] When the next page size is divisible by the candidate page size, i.e., the next page size is an integer multiple of the candidate page size, it indicates that there is a hierarchical mapping relationship between the two page sizes. At this time, the next page size is used as the new expansion alignment reference, and the search for a larger page size continues in the page size sequence.

[0068] Furthermore, the integer multiple relationship judgment is repeatedly performed on the new expansion alignment benchmark, that is, to determine whether the larger page size can be divided by the current expansion alignment benchmark; if the integer multiple relationship is satisfied, the expansion alignment benchmark is further increased until there is no higher-level page size that satisfies the integer multiple relationship.

[0069] When there is no larger page size that satisfies the integer multiple relationship, the currently determined expansion alignment base is used as the final expansion alignment size, so that subsequent requests for contiguous memory regions can be allocated according to this page granularity.

[0070] When there is no integer multiple relationship between the candidate page size and the next page size, it means that a continuous mapping relationship cannot be formed between the two page sizes. In this case, instead of continuing to expand to a larger page size, the candidate page size is directly used as the final expansion alignment size to avoid wasting page space due to the use of a larger page size.

[0071] After determining the expansion alignment size, the required complete alignment interval is calculated based on the requested memory size. Specifically, the requested memory size is divided by the expansion alignment size and rounded up to obtain the number of expansion intervals. Then, the number of expansion intervals is multiplied by the expansion alignment size to obtain the final expansion memory segment size.

[0072] When the final size of the expanded memory segment is greater than the actual requested memory size, the difference between the two is reserved as edge expansion space at the end of the expanded memory segment, and this space is used as a spare area for subsequent small-scale memory requests, instead of being immediately returned to the application.

[0073] Preferably, step S53 further includes: When the maximum page size in the set of page sizes is less than the requested memory size, the maximum page size is determined as the base page size for expansion, and the margin of the requested memory size relative to the maximum page size is obtained; The number of complete expansion units corresponding to the maximum page size is determined based on the margin, and each complete expansion unit is arranged continuously according to the maximum page size, so that the continuous expansion area is aligned with the boundary of the maximum page size. When the margin is insufficient to form a complete expansion unit, the margin is used as the end expansion unit, and the end expansion unit is filled according to the smallest coverable page size in the page size set. The complete expansion unit and the padded end expansion unit are continuously combined to form an expansion range that covers the requested memory size, and the actual allocated size corresponding to the expansion range is used as the alignment size for this expansion.

[0074] In some embodiments, when the address space manager traverses the page size set and finds that all available page sizes in the set are smaller than the current requested memory size, it indicates that a single page size cannot fully cover the current expansion requirement. In this case, the largest page size in the page size set is determined as the base page size for expansion, and this largest page size is used as the basic allocation unit for continuous expansion regions. Subsequently, the requested memory size is divided by the base page size to calculate the number of expansion units that can be covered by the full base page size, and the remaining capacity between the requested memory size and the space covered by the full expansion unit is calculated to obtain the corresponding margin. For example, if the requested memory size exceeds the maximum page capacity supported by the MMU, matching to larger page sizes is no longer pursued; instead, multiple consecutive combinations of the largest page sizes are used to meet the expansion requirement.

[0075] The number of expansion units with the maximum page size that can be fully allocated is determined based on the division between the requested memory size and the base page size of the expansion. Subsequently, the address space manager allocates multiple consecutive expansion units according to the page boundaries corresponding to the maximum page size, arranging these units in a sequential order of page number to ensure no address gaps between adjacent expansion units. During this arrangement, the starting page address of the first expansion unit is used as the starting position of the expansion region, and the addresses of subsequent expansion units are incremented progressively according to the maximum page size. This ensures that the entire consecutive expansion region always meets the maximum page size boundary alignment requirement, thereby guaranteeing that subsequent page table mappings will preferentially use large page mapping.

[0076] When there is still remaining space after the requested memory size is divided into maximum page size expansion units, and the remaining space is smaller than a complete maximum page size expansion unit, this remaining space is identified as the end expansion unit. Subsequently, based on the page granularity supported in the page size set, the smallest page size that can cover the remaining space is searched from smallest to largest, and the end expansion unit is padded according to this page size. Specifically, the actual number of pages corresponding to the remaining space is rounded up so that the number of pages occupied by the end expansion unit meets the MMU page mapping requirements; the excess part generated by padding is retained as end extension space at the end of the expansion region without changing the boundary arrangement of the aforementioned complete expansion units.

[0077] After calculating the maximum page size expansion unit and the end expansion unit, multiple complete expansion units are combined according to page address contiguousness. The padded expansion units are then connected to the end of the contiguous region to form a complete expansion interval. Subsequently, the address space manager recalculates the actual allocation size based on the actual number of pages in the expansion interval and determines this actual allocation size as the alignment size for this expansion. The actual allocation size includes the effective space to satisfy the requested memory size and the edge extension space generated by page granularity padding, ensuring that the final expanded memory segment always conforms to the MMU page mapping constraints.

[0078] Preferably, when the margin is insufficient to form a complete expansion unit, the margin is used as the end expansion unit, and the end expansion unit is padded according to the smallest coverable page size in the page size set. Specifically: Obtain the end-of-line expansion requirement corresponding to the remaining capacity, and match the end-of-line expansion requirement with each page size in the page size set; Determine the smallest page size that is greater than or equal to the end-of-pipe expansion requirement from the set of page sizes, and use it as the end-of-pipe padding size; Adjust the actual allocation range of the end expansion unit according to the end-filling size, so that the end expansion unit covers the end expansion requirement and keeps its starting position continuous with the previous complete expansion unit. The supplemented end expansion units are continuously combined with the complete expansion units to form the final expansion range, and the supplementary space in the end expansion units that exceeds the actual request amount is recorded.

[0079] In some embodiments, after the maximum page size expansion unit partitioning is completed, the difference between the requested memory size and the space covered by the allocated full expansion unit is obtained, and this difference is determined as the end-of-line expansion demand. Subsequently, the end-of-line expansion demand is used as a matching condition and compared with page sizes at various levels in the page size set supported by the MMU to determine the actual page coverage corresponding to the current end-of-line expansion demand. The page size set is arranged in ascending order of page capacity, and matching starts from the smaller page size to avoid wasting extra space in the end-of-line expansion area due to using excessively large page sizes.

[0080] The address space manager reads each page size sequentially from the sorted set of page sizes and determines whether the current page size can cover the end-of-line expansion requirement. If the current page size is smaller than the end-of-line expansion requirement, it continues to obtain the next page size for matching; if the current page size is greater than or equal to the end-of-line expansion requirement, it determines that page size as the end-of-line padding size. By selecting the smallest page size that can cover the end-of-line expansion requirement, the end-of-line expansion unit satisfies the MMU page mapping requirements while limiting the extra space generated by page padding to a minimum.

[0081] The number of pages required for the end-expansion unit is calculated based on the determined end-padding size, and the actual allocation range of the end-expansion unit is expanded according to this number of pages. During the adjustment process, the end address of the previous full expansion unit is used as the starting address of the end-expansion unit, so that the end-expansion unit is directly connected to the previous expansion unit, avoiding unused gap areas between the full expansion unit and the end-expansion unit. Subsequently, the end address of the end-expansion unit is determined according to the end-padding size, so that the end-expansion unit as a whole meets the page boundary alignment requirements and can cover the original end-expansion requirement.

[0082] Multiple complete expansion units allocated according to the maximum page size are concatenated with the padded end expansion units in page address order to form a continuous expansion range. Then, the total capacity of the final expansion range is calculated based on the number of complete expansion units and the actual allocated size of the end expansion units, and this capacity is used as the actual expansion size requested from the address space manager. Simultaneously, the excess space in the end expansion units caused by page padding is marked and recorded as edge extension space in the expanded memory segment, not included in the current application's requested space. When the dynamic memory allocator receives this expansion range, it uses the valid requested space to satisfy the current memory allocation and reserves the edge extension space in the general-purpose heap as a reserve area for subsequent allocation.

[0083] Preferably, adjusting the actual allocation range of the end-capacity expansion unit according to the end-capacity supplementation size, so that the end-capacity expansion unit covers the end-capacity expansion requirement, further includes: Obtain the end address of the previous complete expansion unit, and use the address after the end address as the start address of the last expansion unit; The demand end address of the end expansion unit is determined based on the end expansion demand, and the demand end address is adjusted upward according to the end filling size to obtain the allocation end address of the end expansion unit. Calculate the actual allocation length between the start address and the end address of the end expansion unit, and adjust the actual allocation length to an integer multiple of the end padding size; The final allocation range of the end expansion unit is determined based on the adjusted actual allocation length, so that it is continuous with the previous complete expansion unit and fully covers the end expansion demand.

[0084] In some embodiments, after completing the continuous arrangement of full expansion units according to the maximum page size, the address range information corresponding to the last full expansion unit is obtained, and the end address of that expansion unit is read. Then, the end address is offset backward by one address unit, and the resulting next address is determined as the starting address of the last expansion unit, so that the last expansion unit is directly connected to the previous full expansion unit. By using the end address of the previous full expansion unit as the positioning reference, idle intervals between full expansion units and last expansion units can be avoided, ensuring a continuous address distribution throughout the expansion area.

[0085] Based on the starting address of the end-of-line expansion unit and the end-of-line expansion requirement, the theoretical end address that satisfies the current remaining memory requirement is calculated. Then, the page boundary position corresponding to the end-of-line padding size is obtained, and it is determined whether the theoretical end address is located at that page boundary. If the theoretical end address has not reached the page boundary, it is adjusted to the next page boundary position so that the adjusted address meets the page alignment requirements corresponding to the end-of-line padding size; if the theoretical end address is already at the page boundary position, the current end address remains unchanged. The address after boundary adjustment is determined as the allocation end address of the end-of-line expansion unit, ensuring that the end-of-line expansion unit can fully cover the actual end-of-line expansion requirement and satisfy the MMU page mapping constraints.

[0086] Based on the start address of the end-of-page expansion unit and the adjusted end-of-page allocation address, the address difference between the two is calculated to obtain the actual allocation length of the end-of-page expansion unit. Then, the actual allocation length is compared with the end-of-page padding size to determine if the actual allocation length is divisible by the end-of-page padding size. When the actual allocation length is an integer multiple of the end-of-page padding size, the current actual allocation length remains unchanged; when the actual allocation length does not satisfy the integer multiple relationship, the actual allocation length is rounded up according to the end-of-page padding size, adjusting the actual allocation length to: end-of-page padding size × integer number, resulting in the final allocation length that meets the page granularity requirements. Through the above adjustments, the end-of-page expansion unit can be allocated according to complete page units, avoiding page table mapping anomalies caused by non-integer page lengths.

[0087] Based on the adjusted actual allocation length, the final allocation end address is recalculated using the starting address of the end expansion unit as a reference, and the final address range of the end expansion unit is determined. Subsequently, the finally determined end expansion unit is connected to the previous complete expansion unit, forming a continuous expansion region between the complete expansion unit and the end expansion unit. Simultaneously, the actual allocation range of the end expansion unit is compared with the end expansion requirement to determine the padding space exceeding the actual request, and this space is recorded as the edge extension region in the expanded memory segment. When the subsequent dynamic memory allocator receives this expanded memory segment, it uses the available space that meets the request for the current memory allocation, and reserves the edge extension region as a usable free area in the general heap, thereby satisfying page alignment requirements while reducing subsequent expansion operations.

[0088] Most importantly, the required end address of the end-of-line expansion unit is determined based on the end-of-line expansion demand, and the required end address is adjusted upwards according to the end-of-line filling size. Specifically: Based on the starting address of the end expansion unit and the end expansion demand, calculate the theoretical end address corresponding to the end expansion unit, and use the theoretical end address as the demand end address; Obtain the address boundary granularity corresponding to the end padding size, and determine whether the required end address is located at the end boundary position of the address boundary granularity; When the end address of the demand does not meet the boundary conditions corresponding to the end padding size, calculate the address offset between the end address of the demand and the next boundary position, and determine the padding space that needs to be added based on the address offset. Based on the adjustment of the end address of the padding space, the end address of the demand is moved towards the higher address direction to the nearest end padding size boundary position to obtain the allocation end address; Based on the address range between the allocation end address and the start address of the end expansion unit, the actual allocation length of the end expansion unit is determined, so that the actual allocation length satisfies the page boundary constraints corresponding to the end padding size.

[0089] In some embodiments, after determining the starting address of the end-of-page expansion unit, the current end-of-page expansion requirement is obtained, where the end-of-page expansion requirement represents the amount of additional contiguous memory space needed after the allocation of the maximum page size expansion unit. Then, using the starting address of the end-of-page expansion unit as the address calculation base, the starting address and the end-of-page expansion requirement are added together to obtain the theoretical end address corresponding to the end-of-page expansion unit. Specifically, in the calculation process, the starting address of the end-of-page expansion unit is used as the starting address, and the number of bytes corresponding to the end-of-page expansion requirement is used as the address offset. The theoretical end position that satisfies the actual request requirement is obtained through the address offset, and this theoretical end address is determined as the required end address before page alignment processing.

[0090] After obtaining the end address of the demand, the address space manager reads the page boundary granularity information corresponding to the end padding size. The end padding size limits the minimum mapping granularity of the end expansion unit. Based on this size, the address space manager determines the corresponding boundary partitioning method, dividing the contiguous address space into multiple boundary regions according to the end padding size. Then, it determines whether the location of the demand end address has reached the end boundary corresponding to the current end padding size. When the demand end address is exactly at the end of a boundary region, it indicates that the current end expansion unit already satisfies the page boundary constraints corresponding to the end padding size, and no further adjustment is needed. When the demand end address is inside a boundary region, it indicates that the current address range cannot be directly mapped according to the end padding size, and further calculation of padding space is required.

[0091] When the detected end address of the demand is not located at the end boundary position corresponding to the end padding size, the next page boundary position of the boundary region where the demand end address is located is first determined. Then, the address value of the next boundary position is subtracted from the current demand end address to obtain the address offset between the demand end address and the next boundary position. This address offset represents the additional space required by the current end expansion unit to meet the end padding size requirement. Further, the calculated address offset is used as the padding space size, and the actual allocation range of the end expansion unit is adjusted according to this padding space to ensure that the end expansion unit can cover the entire page boundary.

[0092] Based on the calculated padding space, the demand end address is expanded along the increasing direction of the virtual address. Specifically, the demand end address and the padding space are added together, moving the demand end address to the nearest end padding size boundary. After address adjustment, the adjusted address is determined as the allocation end address of the end expansion unit. The memory range corresponding to the allocation end address not only covers the original end expansion demand but also satisfies the page mapping requirements corresponding to the end padding size, enabling the address space manager to establish a mapping relationship between virtual addresses and physical page frames according to complete page units.

[0093] After obtaining the allocation end address, the address difference between the allocation end address and the start address of the end expansion unit is calculated to obtain the actual allocation length corresponding to the end expansion unit. Subsequently, a page-granularity check is performed on the actual allocation length to determine if it is divisible by the end padding size. When the actual allocation length already satisfies the integer multiple relationship corresponding to the end padding size, the current actual allocation length remains unchanged; when the actual allocation length is insufficient to meet page boundary constraints, the actual allocation length is adjusted upwards according to the end padding size so that the adjusted length corresponds to the number of complete pages. Finally, the actual address range of the end expansion unit is determined based on the adjusted actual allocation length, ensuring that the end expansion unit covers the end expansion requirement while maintaining continuity with the previous complete expansion unit and meeting the boundary alignment requirements in the MMU page mapping process.

[0094] Of particular importance are the methods for determining whether the end address of the requirement is located at the end boundary position of the address boundary granularity, including: Obtain the address boundary granularity corresponding to the end padding size, and determine the continuous boundary interval based on the address boundary granularity, wherein the length of each continuous boundary interval matches the end padding size; Convert the demand end address into the corresponding boundary offset value, and calculate the offset of the demand end address relative to the starting address of the current continuous boundary interval; Determine whether the offset is equal to the correspondence between the address boundary granularity and the preset end offset value; When the offset meets the end boundary condition, it is determined that the required end address is already located at the end boundary position of the address boundary granularity, and no additional padding space is needed. When the offset does not meet the end boundary condition, it is determined that the required end address has not reached the end boundary position corresponding to the address boundary granularity, and the address offset between the required end address and the next boundary position is calculated.

[0095] In some embodiments, after determining the end-padding size, the address space manager reads the page boundary granularity corresponding to that size and divides the virtual address space according to the end-padding size. Specifically, using the start position of the address space as the boundary division benchmark, multiple consecutive boundary intervals are sequentially divided according to the byte length corresponding to the end-padding size, and each consecutive boundary interval corresponds to a complete page mapping range. Each consecutive boundary interval records its corresponding start address and end address, with the end address representing the maximum address position that the boundary interval can cover. Subsequently, by determining whether the required end address is located at that end address position, it is determined whether the current expansion area meets the page boundary requirements.

[0096] Based on the address range of the demand end address, determine its corresponding continuous boundary interval and obtain the starting address of this continuous boundary interval. Convert the demand end address into an offset value relative to the starting address of the current boundary interval, that is, calculate the address difference between the demand end address and the starting address of the current continuous boundary interval. This offset value indicates the specific position of the demand end address within the boundary interval corresponding to the current end padding size.

[0097] Obtain the length of the boundary interval corresponding to the end padding size, and determine the end position offset corresponding to this boundary interval. Compare the calculated required end address offset with the end position offset. When the required end address offset equals the end position offset of the current boundary interval, it indicates that the required end address has reached the last address position of this continuous boundary interval, meaning the current address satisfies the boundary end condition corresponding to the end padding size. When the required end address offset is less than the end position offset, it indicates that the required end address is still within the current boundary interval and has not yet reached the complete page boundary.

[0098] When the offset corresponding to the end address of the demand is detected to be consistent with the boundary end offset, the address space manager determines that the current end-of-line expansion demand has naturally covered the complete end-of-line padding size area. At this point, it indicates that the end address of the demand is already at the end position of the current boundary interval, and the end-of-line expansion unit does not need to add extra page padding space. Subsequently, the current end address of the demand remains unchanged, and this address is directly used as the allocation end position of the end-of-line expansion unit, so that the subsequent actual allocation length can directly meet the page boundary constraints corresponding to the end-of-line padding size.

[0099] When the offset corresponding to the demand end address is not equal to the boundary end offset, it indicates that the demand end address is located inside the current continuous boundary interval. In this case, the address space manager calculates the address difference between the current continuous boundary interval's end address and the demand end address, determining this difference as the padding space that needs to be added. Subsequently, the demand end address is adjusted based on the calculated padding space, moving it towards higher addresses to the boundary end position corresponding to the next end padding size, thus obtaining the allocation end address that meets the page alignment requirements.

[0100] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0101] 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 of the invention herein.

Claims

1. A low-fragmentation, secure memory management method for a real-time operating system, characterized in that, Includes the following steps: Step S1: Establish a two-layer memory management structure of dynamic memory allocator and address space manager, and manage byte-level memory blocks and page blocks respectively; Step S2: Based on the type of memory request, allocate fixed-size objects to fixed-size partitions and allocate other memory requests to the general heap; build an AVL size tree for free memory blocks in the general heap according to block size, and retrieve the smallest free block that is greater than or equal to the request size for allocation; Step S3: For memory release requests, locate adjacent memory blocks based on the boundary markers of the memory blocks, and merge adjacent free blocks; Step S4: Configure boundary protection information in the memory block control header of the general heap, and verify the boundary protection information based on the memory allocation process and the memory release process to detect memory out-of-bounds access; Step S5: When the existing free memory cannot meet the memory allocation request, request contiguous memory from the address space manager through the automatic growth callback function, and determine the expansion alignment size according to the page size supported by the MMU.

2. The low-fragmentation secure memory management method for a real-time operating system according to claim 1, characterized in that, Step S1 includes: Establish a dynamic memory allocator at the upper level, enabling the dynamic memory allocator to receive memory allocation and memory deallocation requests from the application, and using byte-level memory blocks as the basic management object; In the dynamic memory allocator, an AVL size tree is built with the size of the free memory block as the index, and the current memory block size and the previous memory block size are recorded in the control header of each memory block to form a byte-level memory block size index and adjacent positioning structure. An address space manager is established below the dynamic memory allocator, with page blocks as the basic management object. An address tree arranged according to page addresses and a size tree arranged according to the size of free page blocks are established to manage the address information and free capacity of page blocks. By connecting the dynamic memory allocator and the address space manager through an auto-growth callback function, the dynamic memory allocator can initiate a page-level contiguous memory request to the address space manager when the existing byte-level free memory cannot meet the allocation request.

3. The low-fragmentation secure memory management method for a real-time operating system according to claim 2, characterized in that, Step S3 includes the following steps: Step S31: Receive a byte-level memory release request, obtain the corresponding memory block control header based on the memory address to be released, and read the size information of the current memory block and the free flag of the previous memory block; Step S32: Calculate the address of the previous memory block based on the boundary marker of the current memory block, and determine the free state of the previous memory block according to the free flag of the previous memory block; when the previous memory block is in a free state, remove the previous memory block from the free block size tree, and merge the current memory block with the previous memory block. Step S33: Calculate the address of the next memory block based on the size of the merged memory block, and read the free flag of the previous memory block of the next memory block; when the next memory block indicates that the current merged block is in a free state, remove the next memory block from the free block size tree, and merge the next memory block with the current merged block; Step S34: Reinsert the memory block after merging adjacent blocks into the free block size tree according to the size of the merged block, and update the previous free block flag and the previous block size information of the next memory block.

4. The low-fragmentation secure memory management method for a real-time operating system according to claim 3, characterized in that, Step S34 is followed by: For the received page-level memory release request, use the starting page number of the page block to be released as the key to perform a predecessor lookup in the address tree to obtain the adjacent predecessor page block whose page number is less than the starting page number; Determine if the predecessor page block is in an idle state, and determine if the end page number of the predecessor page block is consecutive to the start page number of the page block to be released; if the consecutiveness condition is met, remove the predecessor page block from the address tree and size tree, and merge it with the page block to be released; Using the end page number of the merged page block as the key, perform a successor search in the address tree to obtain the adjacent successor page block whose page number is greater than the end page number; Determine if the successor page block is idle, and determine if the starting page number of the successor page block is consecutive to the ending page number of the merged page block; if the consecutiveness condition is met, remove the successor page block from the address tree and size tree, and merge it with the merged page block; After merging adjacent page blocks, the page blocks are re-inserted into the address tree according to the starting page number, and then inserted into the size tree according to the number of merged pages.

5. The low-fragmentation secure memory management method for a real-time operating system according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: When allocating memory blocks in the general heap, configure boundary protection information in the memory block control header and set a corresponding protection area between the memory block and the user data area; Step S42: Determine the user data area and corresponding protection area of ​​the memory block according to the memory allocation request, and establish a correspondence between the boundary protection information and the memory block; Step S43: Upon receiving a memory release request, obtain the corresponding memory block control header based on the address of the memory to be released, and read the boundary protection information corresponding to the memory block; Step S44: Verify the read boundary protection information with the preset protection information. If the verification is inconsistent, it is determined that there is an out-of-bounds write to the memory block, and the corresponding memory release process is terminated. If the verification is consistent, the memory block is released and adjacent free blocks are merged.

6. The low-fragmentation secure memory management method for a real-time operating system according to claim 1, characterized in that, Step S5 includes the following steps: Step S51: When the dynamic memory allocator cannot obtain a memory block from the existing free block to satisfy the memory allocation request, the automatic growth callback function is triggered, and an expansion request containing the requested memory size is sent to the address space manager. Step S52: The address space manager receives the expansion request, obtains the set of page sizes supported by the current platform through the MMU hardware interface, and determines the candidate page size that is greater than or equal to the requested memory size from the set of page sizes; Step S53: Determine the expansion alignment size based on the multiple relationship between the candidate page size and the larger page size, and adjust the requested memory size upward to an integer multiple of the expansion alignment size; Step S54: Based on the expansion alignment size, allocate a continuous range of virtual addresses in the virtual page pool and allocate corresponding continuous physical page frames in the physical page frame pool, wherein the starting address that matches the expansion alignment size is selected first. Step S55: Establish page table mapping between virtual address and physical address based on the expanded alignment size, and add the expanded memory block with the completed mapping as a new memory segment to the dynamic memory allocator to form a free memory block that can be used for subsequent memory allocation.

7. The low-fragmentation secure memory management method for a real-time operating system according to claim 6, characterized in that, Step S53 includes: The set of page sizes is arranged in ascending order of page size, and the smallest page size that is greater than or equal to the requested memory size is determined as the candidate page size; Get the size of the next page that is larger than the candidate page size, and determine whether the size of the next page is an integer multiple of the candidate page size; When the size of the next page is an integer multiple of the candidate page size, the size of the next page is used as the expansion alignment reference, and it is further determined whether the larger page size corresponding to the expansion alignment reference satisfies the integer multiple relationship, so as to determine the expansion alignment size step by step. When there is no larger page size that satisfies the integer multiple relationship, the currently determined expansion alignment reference is used as the expansion alignment size; when the candidate page size does not satisfy the integer multiple relationship with the larger page size, the candidate page size is directly used as the expansion alignment size. The alignment size is calculated to cover the entire alignment range that can cover the requested memory size, and the remaining space beyond the requested memory size is used as the edge extension space of the expanded memory segment, so that the size of the expanded memory segment is kept as an integer multiple of the alignment size.

8. The low-fragmentation secure memory management method for a real-time operating system according to claim 6, characterized in that, Step S53 also includes: When the maximum page size in the set of page sizes is less than the requested memory size, the maximum page size is determined as the base page size for expansion, and the margin of the requested memory size relative to the maximum page size is obtained; The number of complete expansion units corresponding to the maximum page size is determined based on the margin, and each complete expansion unit is arranged continuously according to the maximum page size, so that the continuous expansion area is aligned with the boundary of the maximum page size. When the margin is insufficient to form a complete expansion unit, the margin is used as the end expansion unit, and the end expansion unit is filled according to the smallest coverable page size in the page size set. The complete expansion unit and the padded end expansion unit are continuously combined to form an expansion range that covers the requested memory size, and the actual allocated size corresponding to the expansion range is used as the alignment size for this expansion.

9. The low-fragmentation secure memory management method for a real-time operating system according to claim 8, characterized in that, When the margin is insufficient to form a complete expansion unit, the margin is used as the end expansion unit, and the end expansion unit is padded according to the smallest coverable page size in the page size set. Specifically: Obtain the end-of-line expansion requirement corresponding to the remaining capacity, and match the end-of-line expansion requirement with each page size in the page size set; Determine the smallest page size that is greater than or equal to the end-of-pipe expansion requirement from the set of page sizes, and use it as the end-of-pipe padding size; Adjust the actual allocation range of the end expansion unit according to the end-filling size, so that the end expansion unit covers the end expansion requirement and keeps its starting position continuous with the previous complete expansion unit. The supplemented end expansion units are continuously combined with the complete expansion units to form the final expansion range, and the supplementary space in the end expansion units that exceeds the actual request amount is recorded.

10. The low-fragmentation secure memory management method for a real-time operating system according to claim 9, characterized in that, Adjusting the actual allocation range of the end-capacity expansion unit based on the end-capacity supplementation size, so that the end-capacity expansion unit covers the end-capacity expansion requirement, also includes: Obtain the end address of the previous complete expansion unit, and use the address after the end address as the start address of the last expansion unit; The demand end address of the end expansion unit is determined based on the end expansion demand, and the demand end address is adjusted upward according to the end filling size to obtain the allocation end address of the end expansion unit. Calculate the actual allocation length between the start address and the end address of the end expansion unit, and adjust the actual allocation length to an integer multiple of the end padding size; The final allocation range of the end expansion unit is determined based on the adjusted actual allocation length, so that it is continuous with the previous complete expansion unit and fully covers the end expansion demand.

Images