Method and system for exchanging local and remote memory objects in single-copy mode
By implementing a memory object swapping method and system in single-copy mode, the problems of data redundancy and address switching overhead in remote memory systems are solved, achieving efficient memory resource utilization and performance scheduling, and meeting the needs of modern data centers.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG UNIV
- Filing Date
- 2026-03-07
- Publication Date
- 2026-07-10
Smart Images
Figure CN122363877A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communications, and more particularly to a method and system for exchanging local and remote memory objects in a single-copy mode. Background Technology
[0002] In modern data centers, memory resources face two major challenges: "memory capacity wall" and "memory idleness". Applications such as deep learning and big data analysis have massive memory requirements that far exceed the local memory capacity of a single server, while the fixed ratio of CPU cores to memory capacity in commercial servers leads to a large amount of memory being idle due to CPU usage or fragmentation issues.
[0003] Remote memory systems, as a solution based on existing commercial hardware, achieve cross-node memory sharing by separately deploying compute nodes and memory nodes, becoming a key technology to overcome the above-mentioned dilemmas.
[0004] Existing remote memory systems are mainly divided into two categories: page-based and object-based solutions. While the object-based solution alleviates the problems of read / write amplification and kernel overhead, the common use of a multi-copy mode leads to data redundancy, low memory utilization, and bottlenecks such as large address space switching overhead and the memory allocator's inability to handle high-frequency requests when multiple processes share memory, which severely limits the system's scalability and operating efficiency. Summary of the Invention
[0005] To address the aforementioned technical problems, this invention proposes a method and system for exchanging local and remote memory objects in a single-copy mode.
[0006] In a first aspect, the present invention proposes a method for exchanging local and remote memory objects in a single-copy mode, comprising the following steps:
[0007] Unified Remote Memory Address Space: Construct a logical address space and deploy it on memory nodes. Divide the address space into a metadata area and an object data area. Use a flat byte-level mapping to establish a correspondence between the unified address space address and the virtual memory address. Then, use a memory management unit to realize the conversion of virtual memory address to physical address.
[0008] A unique replica mode is adopted: when a compute node detects that the local memory pressure exceeds the limit, an object swapping operation is triggered; when a compute process accesses an object that has been swapped out to distant memory, an object swapping-in operation is triggered; and an asynchronous garbage collection mechanism is designed to balance memory release efficiency and system stability.
[0009] Dedicated memory allocation: In the unique replica mode, memory management efficiency is improved through multiple optimizations of the dedicated memory allocator, including:
[0010] Separate memory layout: Physically separates the metadata describing memory blocks from the actual data of the objects for storage;
[0011] Core offloading mechanism: Offload memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core, and eliminate synchronization lock mechanisms between other threads except for atomic operation primitives required for interaction with the allocator thread;
[0012] Multi-partition load balancing: The unified remote memory address space is divided into equal-length partitions. Each partition is managed by a dedicated CPU core and allocator thread. The load index of each partition is monitored in real time by the request scheduler, and memory requests are dynamically scheduled to the partition with the lowest load for processing.
[0013] Secondly, this invention proposes a system for exchanging local and remote memory objects in a single-copy mode, comprising:
[0014] The unified remote memory address space module is used to construct a logical address space and deploy it on memory nodes. It divides the address space into a metadata area and an object data area, and uses a flat byte-level mapping to establish the correspondence between the unified address space address and the virtual memory address. Then, the memory management unit realizes the conversion of virtual memory address to physical address.
[0015] The unique replica mode module is used to trigger object swapping when the compute node detects that the local memory pressure exceeds the limit; and to trigger object swapping in when the compute process accesses an object that has been swapped out to remote memory. An asynchronous garbage collection mechanism is also designed to balance memory release efficiency and system stability.
[0016] A dedicated memory allocation module is used to improve memory management efficiency through multiple optimizations of the dedicated memory allocator in the unique replica mode, including:
[0017] Separate memory layout units physically separate the metadata describing the memory block from the actual data of the object.
[0018] The core unloading mechanism unit offloads memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core. Except for the atomic operation primitives required for interaction with the allocator thread, it cancels the synchronization lock mechanism between other threads.
[0019] The multi-partition load balancing unit divides the unified remote memory address space into equal-length partitions. Each partition is managed by a dedicated CPU core and allocator thread. The request scheduler monitors the load indicators of each partition in real time and dynamically schedules memory requests to the partition with the lowest load for processing.
[0020] The beneficial effects of this invention are:
[0021] This invention employs a unified remote memory address space design, a unique replica mode, and a dedicated memory allocator architecture to achieve efficient support for multiple computing processes from a single memory node.
[0022] This invention avoids inter-process address switching overhead by using a unified address space; it employs a unique replica mode and optimizes object storage strategies to eliminate data redundancy and multi-replica synchronization overhead; and it improves memory allocation efficiency by utilizing a split memory layout, kernel offloading, and multi-partition management mechanisms. This achieves efficient utilization of remote memory resources and high-performance scheduling in multi-process sharing scenarios, adapting to the application needs of modern data centers. Attached Figure Description
[0023] Figure 1 This is a schematic diagram illustrating the data allocation and management process for local and remote memory objects provided in an embodiment of the present invention.
[0024] Figure 2 This is a schematic diagram illustrating the data exchange process between local memory and remote memory objects provided in an embodiment of the present invention. Detailed Implementation
[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0026] Example 1:
[0027] This invention provides a method for exchanging local and remote memory objects in a single-copy mode, comprising the following steps:
[0028] S1: Unify the remote memory address space
[0029] Furthermore, the Unified Remote Memory Address Space (UMA) centrally manages remotely accessible objects of all computing processes by constructing a single logical address space.
[0030] Furthermore, in this embodiment of the invention, the address space is deployed on memory nodes, and its size is consistent with the physical memory capacity of the memory nodes (excluding the kernel space). This abandons the traditional design of independent address spaces for multiple processes, eliminating the need to create a dedicated remote address space for each computing process.
[0031] The address space is internally divided into only two functional modules: the metadata area and the object data area. The metadata area centrally stores the descriptive information of all remotely accessible objects (such as object size, status, index, etc.), while the object data area stores the actual data of the objects, simplifying the address management logic.
[0032] Furthermore, in terms of address translation mechanism, this embodiment of the invention adopts a flat byte-level mapping scheme, which directly establishes a one-to-one correspondence between the unified address space address and the virtual memory address (VMA) of the memory node. Without the need for multi-level page table translation, only one address lookup is required to complete the mapping. Then, the virtual memory address is converted into a physical address through the memory management unit (MMU), which greatly reduces the address translation overhead and provides underlying support for data interaction between multiple processes through remote memory.
[0033] S2: Unique Dungeon Mode
[0034] In this embodiment of the invention, the unique replica mode significantly alleviates memory redundancy by optimizing object storage strategies, while reducing the performance loss caused by multi-replica synchronization.
[0035] In this embodiment of the invention, the operating mechanism of the unique replica mode is as follows:
[0036] When a compute node detects that the local memory pressure exceeds the limit, it triggers an object swapping operation, which transfers the target object data to a memory node. The memory node allocates a memory block of the corresponding size for the object and stores the data. At the same time, the compute node releases the space occupied by the object in its local memory.
[0037] When a computing process accesses an object that has been swapped out to remote memory, an object swapping-in operation is triggered. The memory node reads the object data and transmits it to the computing node. After the computing node loads the object into its local memory, the memory node releases the remote memory block corresponding to the object.
[0038] Furthermore, to avoid performance fluctuations caused by frequent memory block reclamation, the unique replica mode is equipped with an asynchronous reclamation mechanism: a memory block reclamation threshold is set, and reclamation operations are performed in batches only when the number of distant memory blocks to be released in the memory node reaches the threshold, thus balancing memory release efficiency and system operation stability.
[0039] S3: Dedicated memory allocator
[0040] Furthermore, embodiments of the present invention design a dedicated memory allocator, which improves memory management efficiency through multiple optimizations, adapting to large-scale, high-frequency memory request scenarios, specifically including:
[0041] S31: Decoupled memory layout
[0042] Furthermore, the described separate memory layout adopts an architecture design that separates metadata from data, physically separating and storing the metadata describing memory blocks (such as free status identifiers, index information, associated memory block locations, etc.) from the actual object data. By associating metadata with corresponding data blocks through short indexes (such as 16-bit indexes), when searching for free memory blocks, it is only necessary to traverse the metadata area to complete the location, without having to scan the entire memory space. This significantly improves the efficiency of memory block search and management in large-scale object scenarios, while also optimizing memory utilization.
[0043] S32: Core Unloading Mechanism
[0044] Furthermore, the core offloading mechanism offloads all memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core. Except for atomic primitives required for interaction with the allocator thread, synchronization locks between other threads are eliminated: ordinary threads do not need to directly participate in memory metadata operations; they only modify synchronization variables through atomic operations to initiate memory requests to the allocator thread, which then processes all requests serially.
[0045] The core offloading mechanism described in this embodiment of the invention completely eliminates lock overhead caused by multi-threaded contention. At the same time, the dedicated core only runs the allocator thread, avoiding CPU cache line pollution caused by thread switching and ensuring efficient execution of memory management operations.
[0046] S33: Multi-zone load balancing
[0047] Furthermore, the multi-partition load balancing divides the unified remote memory address space into multiple memory partitions of equal length, with each partition allocated a dedicated CPU core and a corresponding allocator thread, forming a "one partition, one core, one thread" management model.
[0048] Furthermore, the multi-partition load balancer is equipped with a request scheduler module that monitors load metrics such as memory utilization and request queue length of each memory partition in real time. Based on statistical data within a fixed time window, it dynamically schedules new memory allocation / release requests to the memory partition with the lowest load. Through a divide-and-conquer strategy, large-scale memory requests are distributed across multiple cores for parallel processing, alleviating the computational pressure on a single core while fully utilizing the computational resources of memory nodes, thereby improving the system's ability to handle high-frequency, large-scale memory requests.
[0049] Example 2: Local and Remote Memory Object Swap Process
[0050] Reference Figure 2In this embodiment, during system operation, data exchange occurs between local memory objects and remote memory objects, including two core processes: swapping out and swapping in. This ensures that under conditions of fluctuating memory pressure or changes in access patterns, this embodiment can efficiently complete object migration and maintain application correctness and performance stability. Specifically, it includes:
[0051] S1: Object swapping process based on single-copy model
[0052] Specifically, the local object swapping process refers to the process by which the system migrates an object from local memory to a remote node when local memory pressure increases or when an object is determined to be accessed infrequently. The process follows a single-copy strategy to ensure that no data copy of the object is retained locally after the swapping is completed.
[0053] In practice, when the runtime detects that an object needs to be swapped out, it first collects the object's structure information, data content, and necessary metadata. Then, the runtime serializes the object and sends it to a remote memory node. The remote node uses its internal allocator to allocate a contiguous storage area for the object from the Uniform Remote Address Space (UMA) based on the object's size and writes the data into that area.
[0054] Furthermore, after the swap-out is complete, the local runtime immediately releases all data of the object in DRAM, retaining only a lightweight proxy structure (such as object ID, remote address identifier, type information, etc.), putting the object in a "remote existence" state. At this point, only the remote node in the entire system stores a unique real copy of the object, avoiding the data synchronization overhead between local and remote nodes in traditional multi-copy mode.
[0055] S2: Remote Object State Management and Access Interception in a Unified Address Space
[0056] Specifically, object state management under a unified address space means that all remote objects are stored in a unified logical address space (UMA) on remote nodes. This space is not isolated according to processes or applications, but is managed uniformly by the system runtime. This approach allows objects created by different applications to be accessed on remote nodes using a unified address, simplifying the remote address location and mapping process.
[0057] Furthermore, when an object is in a remote state, the local runtime only retains its UMA address and necessary metadata. When an application attempts to access the object, the local runtime identifies that the object is no longer in local DRAM through an access interception mechanism and constructs a swap-in request based on its UMA address. This mechanism allows applications to logically not distinguish between local and remote objects; all access can be transparently triggered through the local proxy structure.
[0058] Because UMA uses a flat mapping structure, the address translation overhead of remote nodes is fixed and low, and traditional multi-level page table lookups are not required, thus enabling rapid location of target data during object swapping.
[0059] S3: Object swapping and local recovery based on single-copy model
[0060] Specifically, the object swapping process refers to the process where, when an application accesses an object in a remote state, the system locates its storage location on the remote node using the UMA address and restores the data from the remote node to the local machine according to the single-copy mode.
[0061] During the swap-in process, the remote node reads the object data from the UMA and returns it to its local machine via the network. Subsequently, the local runtime reallocates DRAM space for the object and deserializes the data to restore it to a directly accessible local object structure. Once restored, the local runtime updates the object's status to "locally existing" and releases the corresponding memory block on the remote node, ensuring that the remote node no longer retains a copy of the object. This behavior guarantees the integrity of the single-copy mode, preventing the simultaneous existence of two copies of the data on both the remote and local machines.
[0062] Furthermore, the local runtime updates object access statistics, encouraging frequently swapped-in objects to reside locally for longer periods, thus improving overall access performance. Through this dynamic swapping mechanism, the system can adapt to changes in application access patterns while maintaining a single-copy strategy, achieving efficient utilization of memory resources.
[0063] Example 3: Memory allocation and deallocation process of the allocator
[0064] Reference Figure 1 This embodiment provides the memory allocation process of the allocator, including memory partition initialization, binding of dedicated cores during allocation, and load balancing scheduling, specifically including:
[0065] S1: Initialization based on multi-partition and split layout
[0066] Specifically, initialization based on multi-partition and split layout refers to the allocator dividing the unified memory address space into multiple independent memory partitions of a fixed size during system startup. The number of partitions typically corresponds to the number of CPU cores in the memory nodes, and each memory partition is bound to a dedicated physical core and a corresponding "partition allocator thread." The partition allocator thread runs only on its bound core, avoiding scheduling overhead caused by thread migration across cores, and isolating the memory management operations of each partition from each other, completely eliminating performance interference caused by cross-partition contention.
[0067] Within each partition, the allocator employs a "separate memory layout" structure, further dividing it into two main parts: a metadata area and an object data area. The metadata area is dedicated to recording management information for all memory blocks within that partition, including block size, allocation status (free / used), the index of the next block in the free list, and the identifier of the object it belongs to. This information is centrally managed and not mixed with actual data, making metadata traversal, updating, and merging operations more efficient. The object data area stores the data content of various objects created by the application, and is pre-divided into fixed-size memory blocks according to various specifications (such as 4KB, 8KB, 16KB, ..., 128KB, etc.) to facilitate rapid location and allocation for objects of different sizes.
[0068] During the initialization phase, the allocator creates independent "free block lists" for free blocks of various sizes in the object data area. For example, all 4KB free blocks are linked into one list, all 8KB free blocks into another, and so on. The metadata area records the head pointers of these lists and other necessary index information, enabling the allocator to find suitable free blocks with constant or near-constant time complexity during subsequent allocation operations, reducing traversal overhead.
[0069] Through the above initialization process, the allocator builds a high-efficiency memory management framework with a clear structure, independent partitions, and centralized metadata during the system startup phase. This enables subsequent allocation and release operations to be executed in parallel in a multi-core environment, laying the foundation for high-performance memory management of the entire system.
[0070] S2: Dedicated core-bound memory management
[0071] Specifically, the memory management mechanism based on dedicated core binding refers to the system reserving a separate physical core in the memory node for the memory management thread, so that it is specifically responsible for the allocation, reclamation, merging and metadata update of remote memory objects, thereby avoiding problems such as lock conflicts, cache pollution and queue blocking caused by multi-threaded contention and improving the overall remote memory management performance.
[0072] In actual implementation, the system initializes one or more memory management threads during the memory node startup phase and binds them to designated physical cores, ensuring that they execute only on that core throughout the entire process. The binding operation is implemented through the underlying scheduling interface, including setting thread affinity, disabling core migration, and fixing CPU frequency, ensuring that the operation of the memory management threads is not interfered with by other processes or threads in the system.
[0073] When a memory node receives various remote memory management requests from an external system, such as object allocation, object reclamation, space merging, or metadata updates, these requests are not directly processed by ordinary logic threads. Instead, they are written to the corresponding request buffer of a dedicated core via a lock-free message queue or atomic queue. Since the writer does not need to perform metadata operations or acquire locks, the entire request submission process has extremely low overhead.
[0074] Furthermore, the memory management thread on the binding core continuously consumes these requests in a polling or event-driven manner. Since only this thread can access and modify the corresponding memory metadata, all operations are executed under strictly serial semantics, completely avoiding common multi-threaded problems such as lock contention, atomic synchronization conflicts, and cache line contention. At the same time, this serial execution mode ensures the consistency of the metadata structure at all times, avoiding complex cross-thread synchronization designs.
[0075] Furthermore, to enhance the overall system scalability, the system supports binding multiple dedicated cores simultaneously, with each core responsible for managing an independent remote memory segment. As the system scales up and remote memory requests become more frequent, the memory management pressure can be distributed by adding dedicated cores, thus ensuring that the system's processing capacity does not decrease with increasing load.
[0076] Through the above methods, the system effectively improves the stability of remote memory management in high-concurrency and high-migration scenarios, significantly reduces the latency fluctuations of memory management-related operations, and ensures that the entire memory management process has predictable, smooth, and highly efficient execution characteristics while maintaining metadata consistency and structural integrity.
[0077] S3: Memory allocation and deallocation mechanism based on multi-partition allocator
[0078] Specifically, the memory allocation and release mechanism based on a multi-partition allocator refers to the system dividing the entire manageable memory space into multiple partitions of fixed size. Each partition is equipped with an independent metadata structure and a free management list to improve the locality of memory allocation operations, reduce global contention, and improve overall allocation efficiency under large-scale memory requests. During runtime, the system dynamically selects the most suitable partition to perform allocation or release operations based on the size of the requested object, partition load, and free block distribution.
[0079] In practice, the allocator first initializes multiple memory partitions of equal or unequal length according to preset rules. Each partition contains an independent free list, metadata index, partition usage counter, and record of the largest contiguous free block. The partitions do not interfere with each other and each manages its own memory blocks. At any given time, the system can process allocation or deallocation requests from different partitions simultaneously, thus achieving inherent parallelism.
[0080] When the system receives a memory allocation request, the allocator first determines the target partition based on the requested size. Typically, the system prioritizes partitions that meet the following criteria: sufficient remaining space, low current load, and the ability to provide contiguous free blocks closest to the target size. Within the target partition, the allocator locates a suitable free block using a free list. If the current free block is smaller than the requested size, the list is traversed; if the free block is larger than the requested size, the block is split, the unused portion is added back to the free list, and the corresponding metadata structure is updated. The entire allocation process is completed based on partition-independent linked lists and index operations, without cross-partition coordination, thus ensuring a stable and short-path allocation path.
[0081] During memory release, the system returns the memory block to the corresponding partition for processing based on the partition number to which the object belongs. The release logic includes remounting the memory block to the partition's free list and determining whether to perform a merging operation of adjacent free blocks based on the partition's current state. When it is detected that both the memory block before and after the release block are in a free state, the allocator will automatically perform merging to form a larger contiguous space, reduce fragmentation, and improve the success rate of subsequent large block allocations. At the same time, the system updates the partition's maximum free block record, free space counter, and other metadata information to reflect the latest available space layout of the partition.
[0082] Furthermore, in a multi-partition architecture, the system can perform statistical analysis on the idle status of multiple partitions through periodic scanning or load-triggered strategies. During the statistical process, if one partition has too much idle time and remains unused, while another partition is under strain, the system can appropriately adjust the allocation strategy, prioritizing the scheduling of new requests to the partition with more available space, thus achieving dynamic balancing across partitions and improving global memory management efficiency.
[0083] Through a multi-partition allocation and release mechanism, the system can maintain a stable and orderly memory structure in high-frequency allocation and reclamation scenarios, while significantly reducing fragmentation problems and improving the success rate of large block allocation; and shortening the allocation path from global linked list search to partition-based local search, reducing search depth and improving overall allocation performance.
[0084] Example 4:
[0085] This invention also provides a system for exchanging local and remote memory objects in a single-copy mode, comprising:
[0086] The unified remote memory address space module is used to construct a logical address space and deploy it on memory nodes. It divides the address space into a metadata area and an object data area, and uses a flat byte-level mapping to establish the correspondence between the unified address space address and the virtual memory address. Then, the memory management unit realizes the conversion of virtual memory address to physical address.
[0087] The unique replica mode module is used to trigger object swapping when the compute node detects that the local memory pressure exceeds the limit; and to trigger object swapping in when the compute process accesses an object that has been swapped out to remote memory. An asynchronous garbage collection mechanism is also designed to balance memory release efficiency and system stability.
[0088] A dedicated memory allocator module is used to improve memory management efficiency through multiple optimizations in the unique replica mode, including:
[0089] Separate memory layout units physically separate the metadata describing the memory block from the actual data of the object.
[0090] The core unloading mechanism unit offloads memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core. Except for the atomic operation primitives required for interaction with the allocator thread, it cancels the synchronization lock mechanism between other threads.
[0091] The multi-partition load balancing unit divides the unified remote memory address space into equal-length partitions. Each partition is managed by a dedicated CPU core and allocator thread. The request scheduler monitors the load indicators of each partition in real time and dynamically schedules memory requests to the partition with the lowest load for processing.
[0092] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.
[0093] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for exchanging local and remote memory objects in a single-copy mode, characterized in that, Includes the following steps: Unified Remote Memory Address Space: Construct a logical address space and deploy it on memory nodes. Divide the address space into a metadata area and an object data area. Use a flat byte-level mapping to establish a correspondence between the unified address space address and the virtual memory address. Then, use a memory management unit to realize the conversion of virtual memory address to physical address. The unique replica mode is adopted: when the compute node detects that the local memory pressure exceeds the limit, the object swapping operation is triggered; when the compute process accesses the object that has been swapped out to remote memory, the object swapping in operation is triggered. An asynchronous garbage collection mechanism is designed to balance memory release efficiency with system stability. Dedicated memory allocation: In the unique replica mode, memory management efficiency is improved through multiple optimizations of the dedicated memory allocator, including: Separate memory layout: Physically separates the metadata describing memory blocks from the actual data of the objects for storage; Core offloading mechanism: Offload memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core, and eliminate synchronization lock mechanisms between other threads except for atomic operation primitives required for interaction with the allocator thread; Multi-partition load balancing: The unified remote memory address space is divided into equal-length partitions. Each partition is managed by the dedicated CPU core and allocator thread. The load index of each partition is monitored in real time by the request scheduler, and memory requests are dynamically scheduled to the partition with the lowest load for processing.
2. The method according to claim 1, characterized in that, The size of the memory node is the same as the physical memory capacity, eliminating the need for a separate address space for each process and creating a dedicated remote address space for each process.
3. The method according to claim 1 or 2, characterized in that, The metadata area centrally stores descriptive information of remotely accessible objects, including object size, status, and index; The object data area stores the actual data of the object, simplifying the address management logic.
4. The method according to claim 3, characterized in that, The flattened byte-level mapping is completed with a single address lookup, eliminating the need for multi-level page table conversions.
5. The method according to claim 1, characterized in that, The triggered object swapping operation involves transferring the target object data to the memory node and allocating a corresponding memory block for storage, while simultaneously releasing the space occupied by the target object in local memory. The triggered object swapping operation is as follows: the memory node reads the object data and transmits it to the compute node. After the compute node loads the object into its local memory, the memory node releases the corresponding remote memory block.
6. The method according to claim 1 or 5, characterized in that, The asynchronous recycling mechanism sets a memory block recycling threshold and only recycles memory blocks in batches when the number of unreleased memory blocks reaches a certain threshold, thus balancing release efficiency and system stability.
7. The method according to claim 1, characterized in that, The separate memory layout uses a short index to associate metadata and data blocks. When searching for free memory blocks, only the metadata area needs to be traversed, without scanning the entire memory space.
8. The method according to claim 1 or 7, characterized in that, Under the aforementioned synchronization lock mechanism, ordinary threads do not directly manipulate memory metadata; they only modify synchronization variables and initiate memory requests through atomic operations, and the allocator thread processes all requests serially.
9. The method according to claim 1, characterized in that, The dedicated CPU core runs only the allocator thread, avoiding CPU cache line pollution caused by thread switching.
10. A system for exchanging local and remote memory objects in a single-copy mode, characterized in that, include: The unified remote memory address space module is used to construct a logical address space and deploy it on memory nodes. It divides the address space into a metadata area and an object data area, and uses a flat byte-level mapping to establish the correspondence between the unified address space address and the virtual memory address. Then, the memory management unit realizes the conversion of virtual memory address to physical address. The unique replica mode module is used to trigger an object swapping operation when a compute node detects that the local memory pressure has exceeded the limit; and to trigger an object swapping-in operation when a compute process accesses an object that has been swapped out to remote memory. An asynchronous garbage collection mechanism is designed to balance memory release efficiency with system stability. A dedicated memory allocation module is used to improve memory management efficiency through multiple optimizations of the dedicated memory allocator in the unique replica mode, including: Separate memory layout units physically separate the metadata describing the memory block from the actual data of the object. The core unloading mechanism unit offloads memory allocation and deallocation operations to an independent allocator thread running on a dedicated CPU core. Except for the atomic operation primitives required for interaction with the allocator thread, it cancels the synchronization lock mechanism between other threads. The multi-partition load balancing unit divides the unified remote memory address space into equal-length partitions. Each partition is managed by a dedicated CPU core and allocator thread. The request scheduler monitors the load indicators of each partition in real time and dynamically schedules memory requests to the partition with the lowest load for processing.