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

Abstract

The present application relates to the technical field of memory management. Provided are a memory management method and apparatus, and an electronic device and a storage medium. In the method, the reliability of memory management is improved by means of compilation and instrumentation of multiple-modular redundancy memory management, and modifications of source codes can be reduced, so that the method is compatible with existing memory management mechanisms. The method may comprise the following process: identifying that there is a directive in a compilation object, wherein the directive is used for modifying a memory variable, so as to indicate that the modified memory variable is a target variable that needs to apply for a multiple-modular redundancy memory; and performing compilation and instrumentation on the compilation object to obtain a target code, wherein when an executable code corresponding to the target code is running, the executable code is at least used for applying for N memories corresponding to the target variable, N≥2, and N is an integer.

Description

Memory management method, device, electronic device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 14, 2023, with application number 202311191949.X and application name “Memory Management Method, Device, Electronic Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of memory management technology, and in particular to a memory management method, device, electronic device and storage medium. Background Art

[0003] Harsh business scenarios such as industrial control and aerospace are affected by harsh factors such as electromagnetic radiation and cosmic rays, which may cause various types of failures. Among them, memory failure logic is relatively complex, and there is currently a lack of relatively mature fault-tolerant solutions.

[0004] One solution to memory failures is to improve reliability by upgrading hardware. For example, replacing traditional memory with space-grade multi-mode dynamic random access memory (DRAM). High-reliability hardware like space-grade DRAM can significantly reduce failure rates, but this is often expensive. Statistics show that the cost of space-grade dedicated chips is approximately 1,000 times higher than that of commercial off-the-shelf (COTS) components. This high cost limits the practical application of this memory failure solution. Consequently, a lower-cost fault-tolerance solution is needed to improve the reliability of memory management.

[0005] Summary of the Invention

[0006] The present application provides a memory management method, device, electronic device and storage medium. During the compilation process, multi-module redundant memory management is performed on variables modified by guides through compilation instrumentation, which can reduce costs, reduce failure rates and improve memory management reliability.

[0007] First, embodiments of the present application provide a memory management method, comprising: identifying the presence of a preamble in a compiled object; using the preamble to modify a memory variable to indicate that the modified memory variable is a target variable requiring multi-module redundant memory; instrumenting the compiled object to obtain target code; and, at runtime, executing executable code corresponding to the target code to request at least N shares of memory corresponding to the target variable, where N is an integer and is greater than or equal to 2. Compared to high-reliability hardware such as space-grade hardware, this method significantly reduces costs and is compatible with current memory manager standards, eliminating the need for intrusive shotgun modifications to the source code. This method provides a practical, fault-tolerant memory management solution.

[0008] In a feasible implementation, compilation stubs are performed on the compilation object, including: modifying the memory application interface with the target variable as the object in the compilation object to call a first API; the first API is a multi-module redundant memory application function; the multi-module redundant memory application function is used to apply for at least N copies of memory corresponding to the target variable. The first API is a function for implementing multi-module redundant memory management (memory application), which can be called independently during the compilation process, and there is no need to modify the existing memory application interface in the source code. Instead, it is sufficient to add a modifier guide when defining the variable, which reduces the modification of the source code and helps to achieve one track of the source code; on the other hand, this method of calling the corresponding function through compilation stubs can be compatible with the current general memory management mechanism. For example, it can still use memory management functions such as malloc function and free function in the source code. The executable code (binary code) obtained through compilation stubs can implement multi-module redundant memory management at runtime, solving the problem of incompatibility between multi-module redundant management and traditional memory management (i.e., non-multi-module redundant memory management).

[0009] In one feasible implementation, compile-instrumenting a compiled object includes modifying a read operation targeting a target variable in the compiled object to call a second API; the second API is a multi-module redundant memory read function, which is used to read values ​​stored in at least N memory modules. Similar to the first API, the second API is a function for performing read operations in multi-module redundant memory management and can be independently called during the compilation process. This eliminates the need to modify existing memory read interfaces in the source code, reduces source code modifications, and facilitates single-track source code. Furthermore, the second API is compatible with existing common memory management mechanisms.

[0010] In one feasible implementation, compile-instrumenting a compiled object includes modifying a write operation targeting a target variable in the compiled object to call a third API; the third API is a multi-module redundant memory write function, which is used to write the value of the target variable to at least N copies of memory. Similar to the first API, the third API is a function for performing write operations in multi-module redundant memory management and can be independently called during the compilation process. This eliminates the need to modify existing memory write interfaces in the source code, reduces source code modifications, and facilitates single-track source code. Furthermore, the third API is compatible with existing common memory management mechanisms.

[0011] In one feasible implementation, compiling and instrumenting a compiled object includes modifying the memory release interface in the compiled object, which targets a target variable, to call a fourth API; the fourth API is a multi-module redundant memory release function, which is used to release at least N shares of memory. Similar to the first API, the fourth API is a function for executing release operations in multi-module redundant memory management and can be independently called during the compilation process. This eliminates the need to modify existing memory release interfaces in the source code, reduces source code modifications, and facilitates single-track source code. Furthermore, the fourth API is compatible with existing common memory management mechanisms.

[0012] In a feasible implementation, the executable code corresponding to the target code is also used to apply for a multi-module redundant memory management structure during runtime; the multi-module redundant memory management structure is used to manage N copies of memory; and the multi-module redundant memory release function is used to release N copies of memory and the multi-module redundant memory management structure.

[0013] In one feasible implementation, identifying the presence of a preamble in the compiled object includes: identifying the presence of a preamble in a line of code corresponding to a target variable in the compiled object. The location of the preamble can be flexible and is not limited to being added before the variable, facilitating implementation.

[0014] In one feasible implementation, N copies of memory include 1 main memory block and N-1 backup memory blocks; the target code includes calling a first API; the first API is used to perform the following operations: apply for a multi-module redundant memory management structure; the multi-module redundant management structure includes an object header; the header is used to store at least the base addresses of N-1 backup memory blocks; apply for N copies of memory corresponding to the target variable, and return the base addresses corresponding to the N copies of memory; define the pointer used to access the target variable as a wide pointer; return the wide pointer; the high bit of the wide pointer is used to store the first base address, and the low bit is used to store the first pointer; wherein the first base address is the base address of the main memory block; the first pointer points to the memory address in the main memory block used to store the value of the target variable. This method provides a multi-module memory addressing scheme in a multi-module redundant memory management scenario.

[0015] In a feasible implementation, the target code includes calling a second API; the second API is used to perform the following operations:

[0016] Based on the first base address and the first pointer, determine the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks; wherein the second base address is the base address of the header; the second pointer to the Nth pointer respectively point to the memory addresses in the N-1 backup memory blocks for storing the values ​​of the target variables; read the values ​​in the memory addresses pointed to by the first pointer and the second pointer to the Nth pointer respectively.

[0017] In a feasible implementation, based on the first base address and the first pointer, determining the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks includes: determining the second base address based on the first base address and the first offset; the first offset is the offset of the second base address relative to the first base address, and the first offset is a constant; according to the second base address, reading the base addresses corresponding to the N-1 backup memory blocks respectively; determining the second offset of the memory address pointed to by the first pointer relative to the first base address; and determining the second pointer to the Nth pointer according to the base addresses and the second offsets corresponding to the N-1 backup memory blocks respectively.

[0018] In one feasible implementation, the header is also used to store the N values ​​returned by the first through Nth pointers. When running, the executable code corresponding to the second API is further used to: compare the N values, determine the correct value, and return it as the value of the target variable; determine the faulty memory block; and write the correct value to the faulty memory block. Multi-mode memory arbitration improves the reliability of memory management.

[0019] In a feasible embodiment, the target code includes calling a first API; the first API is used to perform the following operations: apply for N copies of memory corresponding to the target variable; wherein the base address of the tth copy of memory is fixedly offset relative to the base address of the t-1th copy of memory; 2≤t≤N.

[0020] In a feasible implementation, N copies of memory include 1 main memory and N-1 backup memory blocks; the target code includes calling a second API; the executable code corresponding to the second API is used to perform the following operations at runtime: based on the first pointer and the offset of the fixed offset, determine the second pointer to the Nth pointer respectively; wherein the first pointer points to the memory address in the main memory block where the value of the target variable is stored; read the values ​​in the memory addresses pointed to by the first pointer, the second pointer to the Nth pointer respectively through the first pointer, and return them.

[0021] In a feasible implementation, the target code includes calling a first API; the executable code corresponding to the first API is used to perform the following operations when running: applying for a third multi-module redundant memory management structure; the third multi-module redundant management structure includes a first virtual memory area and a second virtual memory area; the first virtual memory area is used to store target variables; the second virtual memory area is used to store memory variables that do not require applying for multi-module redundant memory; within the address space occupied by the first virtual memory area, applying for N copies of memory, and in the N copies of memory, the base address of the tth memory block is fixedly offset relative to the base address of the t-1th memory block; 2≤t≤N.

[0022] In a feasible implementation, after the code corresponding to the memory application interface is compiled and inserted to obtain the first code, the method further includes: identifying a read operation and / or a write operation with the target variable as the object; modifying the code corresponding to the read operation and / or the write operation into a fifth target code through the compiler; the executable code corresponding to the fifth target code is used to perform the following operations at runtime: starting a patrol thread; triggering the patrol thread, and performing the following operations through the patrol thread: writing the value of the target variable into N copies of memory respectively; or reading the value of the N copies of memory corresponding to the target variable; obtaining the correct value based on the arbitration strategy and returning it as the value of the target variable; determining the memory block storing the error; and writing the correct value into the memory block storing the error. This implementation can be applied to large-scale or high-concurrency read / write operation application scenarios, can cope with frequent read / write operations, and reduce the possibility of system crashes.

[0023] In a feasible implementation, when the target variable is a static variable or a global variable, the compilation object is compiled and instrumented to obtain the target code, including: linking the definition of the target variable in the compilation object to the multi-mode data segment of the binary program to obtain the executable code; the executable code is used to apply for N shares of memory corresponding to the target variable when it is loaded or loaded by the operating system.

[0024] In the second aspect, an embodiment of the present application also provides a memory management device, which includes: a preamble recognition module for identifying the presence of a preamble in a compiled object; the preamble is used to modify a target variable, and the target variable is a memory variable that requires application for multi-module redundant memory; a compilation instrumentation module for performing compilation instrumentation on the compiled object to obtain a target code; the executable code corresponding to the target code is used to apply for at least N copies of memory corresponding to the target variable during runtime, where N ≥ 2 and is an integer.

[0025] In a feasible implementation, the compilation stub module is specifically used to modify the memory request interface with the target variable as the object in the compilation object to call the first API; the first API is a multi-module redundant memory request function; the multi-module redundant memory request function is used to apply for at least N copies of memory corresponding to the target variable.

[0026] In a feasible implementation, the compilation stub module is specifically used to modify the read interface with the target variable as the object in the compilation object to call the second API; the second API is a multi-module redundant memory read function; the multi-module redundant memory read function is at least used to read the values ​​stored in N copies of memory.

[0027] In a feasible implementation, the compilation stub module is specifically used to modify the write interface with the target variable as the object in the compilation object to call a third API; the third API is a multi-module redundant memory write function; the multi-module redundant memory write function is at least used to write the value of the target variable into N copies of memory respectively.

[0028] In a feasible implementation, the compilation stub module is specifically used to modify the memory release interface with the target variable as the object in the compilation object to call the fourth API; the fourth API is a multi-module redundant memory release function; the multi-module redundant memory release function is used to release at least N copies of memory.

[0029] In a feasible implementation, N copies of memory include 1 main memory block and N-1 backup memory blocks; the target code includes calling a first API; the first API is used to perform the following operations: apply for a multi-module redundant memory management structure; the multi-module redundant management structure includes an object header; the header is used to store at least the base addresses of N-1 backup memory blocks; apply for N copies of memory corresponding to the target variable, and return the base addresses corresponding to the N copies of memory respectively; define the pointer used to access the target variable as a wide pointer; return the wide pointer; the high bit of the wide pointer is used to store the first base address, and the low bit is used to store the first pointer; wherein the first base address is the base address of the main memory block; the first pointer points to the memory address in the main memory block used to store the value of the target variable.

[0030] In a feasible embodiment, the target code includes calling a second API; the second API is used to perform the following operations: based on the first base address and the first pointer, determine the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks; wherein the second base address is the base address of the header; the second pointer to the Nth pointer respectively point to the memory addresses in the N-1 backup memory blocks for storing the values ​​of the target variables; read the values ​​in the memory addresses pointed to by the first pointer and the second pointer to the Nth pointer respectively.

[0031] In a feasible embodiment, the target code includes calling a first API; the first API is used to perform the following operations: apply for N copies of memory corresponding to the target variable; wherein the base address of the tth copy of memory is fixedly offset relative to the base address of the t-1th copy of memory; 2≤t≤N.

[0032] In a feasible implementation, compilation stubs are performed on the compiled object, including: modifying the read interface and / or write interface in the compiled object with the target variable as the object into code for performing the following operations: pulling up a patrol thread; triggering the patrol thread, the patrol thread is used to: write the value of the target variable into N copies of memory respectively; or read the values ​​in N copies of memory corresponding to the target variable; compare the values ​​in the N copies of memory, obtain the correct value based on the arbitration strategy, and return it as the value of the target variable.

[0033] In a feasible implementation, when the target variable is a static variable or a global variable, the compilation object is compiled and instrumented to obtain the target code, including: linking the definition of the target variable in the compilation object to the multi-mode data segment of the binary program to obtain the executable code; the executable code is used to apply for N shares of memory corresponding to the target variable when it is loaded or loaded by the operating system.

[0034] On the third aspect, an embodiment of the present application also provides a computer program product, which includes a program; the program includes a lead, which is used to modify the target variable, and the target variable is a memory variable that needs to apply for multi-module redundant memory; the target code corresponding to the program is at least used to apply for N copies of memory corresponding to the target variable; wherein the target code includes the code obtained by compiling and instrumenting the program; N≥2 and is an integer.

[0035] In a fourth aspect, an embodiment of the present application further provides a computer program product, which includes a program. When the program is executed by an electronic device, the electronic device implements the method as described in any one of the above-mentioned first aspects.

[0036] In a fifth aspect, an embodiment of the present application also provides an electronic device for sending data through a data transmission interface, the electronic device comprising: one or more processors; a memory; at least one application; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions, which, when executed by the electronic device, enable the electronic device to execute a method as described in any one of the above-mentioned first aspects.

[0037] In a sixth aspect, an embodiment of the present application further provides a storage medium comprising computer instructions, which, when executed on an electronic device, enables the electronic device to execute a method as described in any one of the above-mentioned first aspects.

[0038] In the seventh aspect, an embodiment of the present application also provides a chip system, comprising: a communication interface for inputting and / or outputting data; a processor for executing a computer executable program so that a device equipped with the chip system executes a method as described in any one of the above-mentioned first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 is an example diagram of a full fault scenario mode;

[0040] FIG2 is a schematic diagram of an application scenario of the memory management method provided in an embodiment of the present application;

[0041] FIG3 is a schematic diagram of the architecture of the method of related technology 2;

[0042] FIG4 is a schematic diagram of the architecture of an embodiment of a memory management method provided by the present application;

[0043] FIG5 is a schematic diagram of a system architecture corresponding to the related technology 2;

[0044] FIG6 is a schematic diagram comparing an embodiment of a memory management method provided by the present application with related technologies and prior art;

[0045] FIG7 is a schematic diagram of the system architecture of dynamic memory management in the memory management method provided by this application;

[0046] FIG8 is a schematic diagram of a compiler architecture in one embodiment of the memory management method provided by the present application;

[0047] FIG9 is a schematic diagram of the system architecture of static memory management in the memory management method provided by this application;

[0048] FIG10 is a schematic diagram comparing a specified preamble and no preamble under static memory management in one embodiment of the memory management method provided by the present application;

[0049] FIG11 is a schematic diagram of compilation instrumentation in a specific embodiment of the memory management method provided by the present application;

[0050] FIG12 is a schematic diagram of compilation instrumentation in another specific embodiment of the memory management method provided by the present application;

[0051] FIG13 is a schematic diagram of compilation instrumentation in another specific embodiment of the memory management method provided by the present application;

[0052] FIG14 is a schematic diagram of launching a patrol thread in yet another specific embodiment of the memory management method provided by the present application;

[0053] FIG15 is a schematic diagram of the hardware structure of the electronic device. DETAILED DESCRIPTION

[0054] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0055] The terms used in the implementation section of this application are only used to explain the specific embodiments of this application and are not intended to limit this application.

[0056] As shown in Figure 1, in demanding business applications such as industrial control and aerospace, hardware may experience faults such as tripping, locking, burning, hanging, and link interruption due to adverse factors such as electromagnetic radiation (such as cosmic rays), process problems, device aging, high and low temperature, load, electromigration, stress migration, negative bias temperature instability, hot carrier injection, and humidity. If hardware faults are not promptly addressed, software faults such as UnACE (Architecturally Correct Execution), DUE (Detected Unrecoverable Error), SDC (Silent Data Corruption), CEE (Corrupt Execution Errors), SCEE (Silent Corrupt Execution Error), interrupt loss, and resource leakage can affect application business behavior and lead to business-layer faults such as business function errors, business interruptions, business timeouts, and business DFX failures.

[0057] From a macro perspective, common fault types can be categorized as memory failures, external storage failures, link failures, and CPU failures. For CPU failures, hardware-based Lock-Step is generally used as the mainstream CPU fault tolerance technology. CPUs that support the Lock-Step architecture consist of two processors that monitor each other. External storage failures, due to their long lifecycle, have relatively simple logic. Link failures rely on hardware or protocol fault tolerance. Finally, due to the complex logic of memory failures, there is currently a lack of fault tolerance solutions.

[0058] Stack memory failures and heap memory failures are both types of memory failures. Compared to stack memory, which has a short lifespan and concentrated code and data segments, heap memory, with its varying lifespans, dispersed locations, and a high proportion of business memory, accounts for up to 95%, making it a major factor affecting memory reliability. Therefore, ensuring heap memory reliability is a core challenge in the industrial control and aerospace sectors.

[0059] In order to understand the improvements made to the solution proposed in the embodiment of the present application, two related technologies are listed below for illustration.

[0060] In related technology 1, memory failures such as heap memory failures are addressed through hardware upgrades and modifications. This approach reduces the failure rate by configuring highly reliable specialized hardware such as aerospace-grade multi-mode DRAM. For example, the high-reliability multi-mode redundant DRAM Teledyne e2v, launched in 2020, uses four additional DRAM chips, or five bare-die DRAM chips, compared to traditional DRAM. This increases system-level error detection capabilities, implements multi-mode redundant memory in hardware, and improves reliability. However, this solution has the following drawbacks:

[0061] The cost of specialized chips and other devices is high: For example, in aerospace scenarios, it has been documented that the failure rate of CTOS devices is approximately 100,000 times higher than that of space-grade devices. This means that the failure rate of space-grade specialized devices can be reduced to approximately one hundred thousandth of that of ordinary CTOS devices. However, the cost of specialized high-reliability devices such as space-grade devices is approximately 1,000 times higher than that of COTS.

[0062] Slow technological evolution: Space-grade devices are small in quantity, have high reliability requirements, and use conservative technology and processes, resulting in much slower iterative evolution than CTOS devices.

[0063] Small storage space: Redundant storage space, additional system-level error detection circuits, and conservative process technology make the storage space of aerospace-grade DRAM several times smaller than that of COTS devices.

[0064] In Related Technology 2, the solution to memory failures is to improve reliability by implementing multi-module redundant memory management through software. To achieve multi-module redundant memory management, this solution adds a multi-module redundant arbitration layer based on the traditional memory allocator. Through a new API, multiple independent memory blocks can be read and written simultaneously, achieving multi-module redundant memory access.

[0065] During their research, the inventors discovered that this solution requires adding new memory management interfaces to the source code. For example, to implement multi-module redundant memory allocation, release, reading, and writing, the corresponding memory allocation, release, read, and write interfaces must be added to the source code. These new interfaces are equivalent to adding a set of interfaces independent of the existing general memory manager and are incompatible with commonly used memory managers, such as ptmalloc.

[0066] For example, in the ptmalloc memory manager, the malloc function and free function can be used to implement memory allocation and memory release, respectively. However, in this solution, the malloc function and free function cannot be used to implement the allocation and release of multi-module redundant memory variables, and pointers cannot be directly used for read and write operations like malloc.

[0067] As a result, due to incompatibility issues, it's impossible to implement the same code base for both unreliable and highly reliable scenarios. Pre-implementing multi-module redundant memory management requires invasive shotgun hardening modifications to historical source code versions, which, for large-scale software code, reduces code quality and maintenance costs unacceptably.

[0068] It can be seen that in the relevant technologies, high-reliability hardware is expensive; the solution of adding a dedicated multi-module redundant memory interface to the software is incompatible with the methods used in unreliable scenarios (malloc, free, pointer access), and requires shotgun modification.

[0069] In the fields of industrial control and aerospace, there is a widespread demand for business-transparent multi-module redundant memory management and execution efficiency. As a new infrastructure information network and a global seamless network integrating the sky and the earth, the satellite communication network has an important impact on the development of many fields such as future communications (such as 6G) and needs to have high reliability. Due to the demands of cost, computing power, and rapid iteration, the satellite communication field is turning to the use of COTS components. However, the failure rate of COTS in strong radiation environments increases by nearly 10%. 5 The reliability pain points brought about by this transformation require aerospace software to increase the implementation of multi-mode redundancy to ensure its error detection and fault tolerance capabilities.

[0070] As satellite business and scale expand, the code size has grown from the traditional hundreds of thousands to tens of millions. How to avoid code-invasive shotgun reinforcement has become particularly important. Therefore, solving problems such as code quality and maintenance costs caused by shotgun modifications introduced by multi-mode redundancy has become a key demand.

[0071] In view of this, an embodiment of the present application proposes a new memory management solution to address the above challenges.

[0072] As shown in Figure 2, the solution provided by the embodiment of the present application can be applied to high-reliability application scenarios such as industrial control, aerospace, satellite communications, railways, nuclear power plants, and medical care. It can also be applied to various application scenarios in daily life and production that have high requirements for memory reliability. For example, it can be applied to application scenarios where banks, government agencies, and other entities store important data information.

[0073] The embodiment of the present application proposes a new multi-module redundant memory management solution. It does not require adding a new API to the source code. Instead, during the compilation process, for variables modified by adding a preamble, at least one of the memory application interface, memory release interface, memory read interface, and memory write interface with the variable as the execution object is compiled into a call to the plug-in function (multi-module redundant memory management interface). This achieves multi-module redundant memory management without modifying the memory management interface in the source code, and is compatible with memory managers such as ptmalloc. That is, it is possible to achieve the various functions of the ptmalloc manager without modifying the various memory application, release, and read / write interfaces in the source code. However, after compilation, when the executable code is running, multi-module redundant memory management is executed for the variables with the added preamble.

[0074] To facilitate understanding of the solutions proposed in the embodiments of this application, the relevant terms are briefly explained:

[0075] Directive: A compilation guide statement, commonly used in heterogeneous programming (such as CUDA), which guides the compiler to generate auxiliary instructions other than source program instructions to fully utilize the characteristics of heterogeneous hardware and maximize system performance. This embodiment of the present application introduces directives into multi-mode redundant memory management for the first time, allowing multi-mode memory reinforcement to be implemented without modifying the business code, allowing multi-mode memory reinforcement and traditional memory allocation to coexist, and realizing one-track versions of the business code for multi-mode memory reinforcement and traditional memory allocation.

[0076] One Track: A software development model that utilizes a single code repository trunk. This trunk is used throughout the development of multiple versions of the entire product, allowing for continuous delivery through iteration to meet user needs. One Track reduces the number of concurrently developed versions of different products, minimizes branching and synchronization waste, and enables continuous evolution of a single set of code, benefiting multiple software versions simultaneously. This significantly shortens development time, reduces code maintenance costs, and ensures code quality. Related technologies that add new call interfaces to the source code are incompatible with previous software code versions, making One Track impossible.

[0077] As shown in Figure 2, the method proposed in the embodiment of the present application can be upgraded based on the original code repository trunk to implement multi-module redundant memory management and improve reliability. For example, this can be achieved by adding a functional plug-in during the compilation process. XMR Pass is a functional plug-in that upgrades multi-module redundant management. This functional plug-in can be added to the Pass pipeline sequence during the compilation process to implement compilation instrumentation without making significant modifications to the source code.

[0078] Multi-modular Redundancy (MMR): A fault-tolerance technology that uses multiple independent modules to perform the same task. This technology uses consistency comparison to identify and correct faulty modules, ensuring system operation even in the event of a fault. If one module fails, the remaining modules continue to operate. Consistency comparison is then used to identify and correct the faulty module, ensuring system reliability and stability.

[0079] The principle of multi-module redundancy (MMR) technology is based on the principles of probability and statistics. Assuming the failure probability of each module is independent, the probability of multiple modules failing simultaneously is extremely small, often negligible. Therefore, MMR can effectively improve system reliability and stability. MMR technology is widely used in high-reliability sectors such as aerospace, railways, and nuclear power plants to ensure safe operation in extreme environments.

[0080] Triple modular redundancy (TMR): uses three independent modules to construct multi-module redundancy technology, which is called triple modular redundancy technology.

[0081] Multi-module redundant memory management (MMR MM): A highly reliable memory allocator that can use multiple independent memory pools to allocate memory. Each memory pool is independent and can be in different physical locations or different virtual address spaces. When a user requests a memory block, the allocator obtains a memory block of the same capacity from multiple independent memory pools and returns it to the user. When one of the memory blocks fails, the faulty memory block can be identified by comparing the contents of different memory blocks for consistency, and the error of the faulty memory block can be corrected to achieve highly reliable memory management. Multi-module redundant memory allocators are commonly used in high-reliability and high-availability systems, such as in aerospace, railways, medical and other fields. It can effectively avoid single point failures and improve the fault tolerance and reliability of the system.

[0082] Triple Modular Redundant Memory Management (TMR MM): Multi-module redundant memory management that allocates memory from three independent memory pools is called triple modular redundant memory management.

[0083] Application Programming Interface (API), in the embodiment of the present application, the API is a predefined function for calling.

[0084] In order to more intuitively compare the improvements made to the solutions proposed in the embodiments of the present application, exemplarily, as shown in Figures 3 and 4, Figure 3 is a schematic diagram of the related technical solution, and Figure 4 is a schematic diagram of the new solution proposed in the embodiments of the present application. As shown in Figure 3, in the related technology, multiple dedicated APIs for multi-module redundancy management are newly added, and it is necessary to significantly modify the source code, add a calling interface for the dedicated API in the source code, or add a corresponding API code. As shown in Figure 3, new calling interfaces for the dedicated API are added to the source code, namely ***malloc(), ***free(), ***read(), and ***write(). After compilation, the executable code executes the corresponding operations of each API when it is running. "***malloc()" and the like indicate calls to the newly added dedicated API, which are two different interfaces from the calling interface in the current general memory manager and are therefore incompatible, or in other words, incompatible with the memory management interface used in the code repository trunk.

[0085] In the solution provided in the embodiment of the present application, as shown in Figure 4, in the source code, there is no need to modify the original interface. Instead, the malloc() function, free() function, read() function and write() function can continue to be called. It is only necessary to add a lead to modify the variable when defining the variable. During the compilation stage, for various interfaces corresponding to variables modified by the lead, such as the memory application interface for calling the malloc() function, the write interface for calling the write() function, the read interface for calling the read() function and the release interface for calling the free() function, during the compilation stage, they are compiled into a dedicated interface for multi-module redundant memory management through the compiler, for example, they are compiled into calling the first API, calling the second API, calling the third API and calling the fourth API respectively to obtain the compiled target code.

[0086] The first through fourth APIs are instrumented functions that can be pre-added to library functions for easy invocation. When the executable code corresponding to the target code is run, the first API is used to request at least N memory blocks, the second API is used to write variable values ​​to at least N memory blocks, the third API is used to read values ​​from at least N memory blocks, and the fourth API is used to release at least N memory blocks. The second and third APIs can also perform consistency comparisons, arbitration, and error correction on the values ​​of multiple memory blocks.

[0087] It should be noted that, in Figure 4, the first API to the fourth API are marked with dotted boxes, indicating that in some embodiments, the first API to the fourth API can be called during the compilation stage; in other embodiments, the codes of the first API to the fourth API can be directly added to the target code, that is, the various interfaces such as memory application in the source code are compiled into the code of the corresponding API, and the API is directly executed at runtime without calling the corresponding API again.

[0088] In addition, the solution proposed in the embodiment of the present application can be executed based on the ordinary memory allocator as shown in Figure 5, that is, it can be compatible with at least one memory manager among ptmalloc, jemalloc, and tcmalloc without the need to add a dedicated memory allocator.

[0089] The solution in the related art needs to be executed on the basis of the triple-module redundant fault-tolerant memory allocator as shown in Figure 5, which means it is not compatible with the current general-purpose memory allocator. It is necessary to add a dedicated triple-module redundant fault-tolerant memory allocator, for example, to add a multi-module redundant arbitration layer to realize the application / release / read / write and consistency arbitration and error correction of multi-module memory, and then realize multi-module redundant memory access through the newly added multi-module read and write API.

[0090] As shown in Figure 6, the solution proposed in the embodiment of the present application (the solution labeled ③) can be executed based on ordinary memory allocation managers ① such as ptmalloc. There is no need to add a special manager. It is only necessary to add a modifying preamble before the memory variable. Compared with the shotgun modification in the related technology ②, the modification of the source code is significantly reduced. For example, it is only necessary to add the preamble "_tmr" before the pointer variable "*p", which can be implemented through macro definition; the code of the non-high-reliability scenario is almost completely consistent with the code of the high-reliability reinforcement scenario (except for a small number of preambles), ensuring the onetrack of software versions in different scenarios.

[0091] The above comparison is for illustrative purposes only and is not intended to limit the method provided in the embodiments of the present application.

[0092] Specifically, the memory management method provided in the embodiments of the present application can be used to perform dynamic memory allocation or static memory allocation, and can be run at both kernel-mode and user-mode operating system operating levels. Thus, the method provided in the embodiments of the present application can be applied to four scenarios in two categories: user-mode multi-module redundant dynamic memory management (such as ptmalloc), kernel-mode multi-module redundant dynamic memory management (such as kalloc), user-mode multi-module redundant static memory management, and kernel-mode multi-module redundant static memory management.

[0093] The following describes the method proposed in the embodiment of the present application from the two perspectives of dynamic memory management and static memory management.

[0094] In a dynamic memory management (user mode or kernel mode) scenario, the memory management method proposed in the embodiment of the present application can be implemented during the compilation process, and specifically may include the following process:

[0095] S1, recognizes the presence of a lead in the compiled object.

[0096] A preamble modifies a memory variable. The preamble modifies the memory variable that requires multi-module redundant memory. The preamble serves as an identifier, allowing the compiler to distinguish between variables requiring multi-module redundant memory management and those that do not.

[0097] In some embodiments, a lead-in can be added to the source code to be compiled as a modified lead-in for a memory variable, without adding a new API or a new calling interface to the source code. For example, if the source code needs to call a POSIX-compatible memory application API (i.e., a memory application interface) and apply for multi-module redundant memory, a multi-module redundant lead-in (such as __xmr) is added before receiving the definition of the memory variable. Then, the memory application interface modified with the lead-in is: __xmr char*p=malloc(size). Optionally, the lead-in can be added to the source code in a unified manner as a macro definition, without the need to manually modify each one.

[0098] The lead-in may specifically be a character or character combination that can serve as an identifier, for example, one or more combinations of numbers, letters, and special symbols. For example, the lead-in may specifically be "XMR", "xmr", "_XMR", "XMR_", "MMR", "TMR", "MMR_", "5MR", "MR5_", "M3R&", etc. Any character that can serve as a modification and identifier may be used as a specific expression form of the lead-in, and the embodiments of this application will not be enumerated. The following description will mostly take "MMR" or "TMR" as an example.

[0099] The compiled object, i.e., the code to be compiled, may be source code or intermediate code. The compilation of high-level language source code can be divided into front-end processing, mid-end processing, and back-end processing. The method provided in the embodiments of the present application can be implemented before the source code is compiled into binary code, for example, in the mid-end processing. Therefore, the compiled object is the intermediate code that has undergone front-end processing.

[0100] For example, if the source code is in C / C++, the compilation process is: preprocessing → compilation → assembly → linking, and then generating executable code (i.e., binary code). The compiled object can be the intermediate code after preprocessing. If the source code is in Java, the corresponding compilation process is: the source code with a .java extension is compiled into a Java bytecode file (.class file) by a Java compiler (such as javac). The compiled object is the source code with a .java extension.

[0101] The preamble in the compiled object can be added to the code, such as the source code, before the compiled object is compiled. In some embodiments, the preamble in the source code can be added through macro definitions to uniformly add modifying preambles to variables that require multi-module redundant memory management.

[0102] It should be noted that in the embodiment of the present application, multi-module redundant memory management includes one or more of a variety of operations such as multi-module redundant memory application, multi-module redundant memory release, multi-module redundant memory reading, multi-module redundant memory writing, multi-module redundant memory arbitration and correction.

[0103] For ease of description, memory variables that require multi-module redundant memory management are defined as target variables, and memory variables that do not require multi-module redundant memory management are defined as ordinary memory variables.

[0104] In some embodiments, the introduction can be added to the code line corresponding to the target variable. The code line corresponding to the target variable can be the code line where the code defining the target variable is located. This code line is defined as the target code line. The code line corresponding to the target variable can be the target code line or another code line within a preset range of the target code line.

[0105] For example, in a dynamic memory management scenario, the target variable is *p, then the target code line corresponding to the target variable is: __xmr char*p = malloc(size). Among them, __xmr is a preamble, char*p is the code that defines the target variable, and the code line where the code that defines the target variable *p is located is: __xmr char*p = malloc(size), which is the target code line. malloc(size) is a memory neural interface that calls the malloc function. In this embodiment, the preamble is added before the target variable. In other embodiments, the preamble can be added to other locations, such as after the target variable, and the resulting code line (target code line) is: char*p__xmr = malloc(size); or the preamble can be added after the memory application interface, and the resulting code line (target code line) is: char*p = malloc(size)__xmr; or, it can also be added between the target variable type definition character char and the target variable *p, and the resulting code line (target code line) is: char__xmr*p = malloc(size).

[0106] In other embodiments, the introduction can also be added to the code line adjacent to or close to the target code line, for example, in the above example

[0107] __xmr char*p=malloc(size)

[0108] The code can be changed to the following:

[0109] __xmr

[0110] char*p=malloc(size)

[0111] This code example shows a preamble as a separate line of code, appearing adjacent to or near the target code line. This means the preamble can appear on the line before or after char*p=malloc(size), or a preset number of lines before or after it. It serves as a marker for the target variable during compilation. In practice, the farther the preamble is from the target variable, the more difficult it is to compile. "__xmr" is for example only and can be replaced with other characters.

[0112] In the static memory management scenario, the introduction is also added to the code line corresponding to the code that defines the target variable. However, in the static memory management scenario, the allocation of multi-module redundant memory does not require calling the memory allocation function. For example, there is no need to call the malloc function, so there is no memory allocation interface. In this case, the introduction can be added before or after char*p, or between char and *p, or added to adjacent or similar code lines.

[0113] Accordingly, when identifying the presence of a preamble in a compiled object, the identification method corresponds to the method in which the preamble was added. For example, if the preamble is added before the target variable, then the identification process will need to analyze whether the preamble exists before the memory variable that appears in the code. If the preamble is added after the memory allocation interface, then the identification process can query whether the preamble exists after the memory allocation interface.

[0114] In an embodiment of the present application, it is supported to add a modifier to various types of memory variables. For example, the modified memory variable can be auto (local variable), extern (global variable) or static variable, etc. Static variables include global variables and local variables with the keyword static as the storage type description. Depending on the data type stored, the memory variable can be one or more of a numeric type, a character type, a date type, a date and time type, a logical type and a currency type. For example, char*p is a character type variable. Compatible with the current memory manager (such as ptmalloc), the solution provided by the embodiment of the present application supports accessing memory variables in the form of pointers.

[0115] It should be noted that the embodiments of the present application mostly use the malloc function as the memory request API for illustrative explanation. In fact, the solutions provided in the embodiments of the present application can also be applied to the calloc function or the realloc function.

[0116] S2, compile the object and obtain the target code.

[0117] When the executable code corresponding to the target code is run, it is used to apply for at least N memory portions (eg, N memory blocks) corresponding to the target variable, where N is ≥ 2 and is an integer.

[0118] In some embodiments, compiling and instrumenting a compiled object involves at least modifying the memory allocation interface in the compiled object, which uses a target variable as an object, to call a first API. The executable code corresponding to the first API, when executed, is used to allocate at least N memory shares corresponding to the target variable. The first API is a function for executing multi-module redundant memory allocations and can be predefined and added to a library function.

[0119] Exemplarily, before the compiler compiles the code into an executable binary program, it will call the multi-module redundant memory request interface for the memory request interface that adds the multi-module redundant preamble, and request multiple copies of memory of the same capacity from multiple memory pools, for example, request N copies of memory, and request a multi-module redundant memory management structure to uniformly manage multiple memory blocks, and at least return the addresses of multiple memory blocks. In some embodiments, the address of the multi-module redundant memory management structure can also be returned.

[0120] In some embodiments, instrumenting a compiled object further includes modifying a read operation on a target variable in the compiled object to call a second API. The second API is a function that performs a read operation on a multi-module redundant memory. The executable code corresponding to the second API is used to read values ​​stored in at least N copies of memory at runtime.

[0121] In the same or other embodiments, compiling and instrumenting a compiled object may further include modifying a write operation targeting a target variable in the compiled object to call a third API. The third API is a function that performs a write operation to the multi-module redundant memory. The executable code corresponding to the third API, when executed, is configured to write at least the value of the target variable to each of the N copies of memory.

[0122] For example, the memory read interface example in the source code is a=*p. Because *p specifies the multi-module redundant directive when applying for memory, that is, *p is a memory variable, the compiler will convert the pointer read access form (such as *p) into a call to the multi-module redundant memory read interface (third API), such as __xmr_read, before compiling the code a=*p into an executable binary program. The multi-module redundant memory read interface (__xmr_read) reads the values ​​in N copies of memory in sequence, reads their contents in sequence, and checks the consistency of multiple copies of memory. For inconsistent memory, correct its errors. In some embodiments, the addresses of multiple memory blocks can be stored in a multi-module redundant memory management structure. The multi-module redundant memory read interface (__xmr_read) reads the specified multiple copies of memory according to the multi-module redundant memory management structure and returns the correct memory value in the multiple copies of memory.

[0123] For another example, the memory write interface example in the source code is *p=10. Since *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer write access form (such as *p) into a call to the multi-module redundant memory write interface (second API), such as __xmr_write, before compiling the code into an executable binary program. The multi-module redundant memory write interface (such as __xmr_write) updates the value of each memory in turn and checks the consistency of multiple memories. For inconsistent memories, it corrects the errors and returns the value of the correct memory in the multiple memories. In some embodiments, the addresses of multiple memory blocks can optionally be stored in a multi-module redundant memory management structure. The multi-module redundant memory write interface (__xmr_write) writes the value of *p to the specified multiple memories in turn according to the multi-module redundant memory management structure and returns the value of the correct memory in the multiple memories.

[0124] Similarly, when compiling a release interface, the memory release interface in the compiled object, targeting the target variable, is modified to call a fourth API. This fourth API is a function that executes the multi-module redundant memory release. The executable code corresponding to the fourth API is used to release at least N copies of memory at runtime.

[0125] For example, in the source code, the compiler uses the free(p) method to determine whether the memory variable to be released is a regular memory variable or a target variable requiring multi-module redundant memory management. For target variables, the compiler sequentially releases the multiple memory blocks allocated by malloc and then releases the multi-module redundant memory management structure. For regular memory variables, the compiler simply releases the memory space they occupy.

[0126] Specifically, the memory request interface with the target variable as the object in the compilation object is modified to call the first API, which can be achieved by modifying and compiling the code corresponding to the memory request interface in the source code into the code that calls the first API.

[0127] For example, as shown in Figure 7, Figure 7 shows a feasible system architecture for dynamic memory allocation, which includes a compiler and a user-mode / kernel-mode multi-module redundant dynamic memory manager. The user-mode / kernel-mode multi-module redundant dynamic memory manager includes multiple memory pools and a multi-module redundant memory management structure.

[0128] During the compilation process, the compiler recognizes "__xmr char*p=malloc(size)" in the source code and the presence of the introduction "__xmr". Therefore, the code corresponding to the memory application interface "__xmr char*p=malloc(size)" needs to be compiled into the code that calls the first API through the compiler XMR plug-in: "_xmr malloc(i32%size)", where "_xmr malloc" is the function name of the first API.

[0129] In the source code shown in FIG7 , a=*p is a read operation with the target variable *p as the object. During compilation, the compiler XMR plug-in compiles it into code that calls the third API: “call void@tmr_read(i8*%p,i32 1)”, where “tmr_read” is the function name of the third API.

[0130] *p=10 is a write operation with the target variable *p as the object. During compilation, the compiler XMR plug-in compiles it into the code that calls the second API: "call void@tmr_write(i8*%p,i8 10)", where "tmr_write" is the function name of the second API.

[0131] After compilation and instrumentation, the resulting target code can execute at least N memory allocations, N memory writes, N memory reads, and N memory releases at runtime. N = 3 represents triple-mode memory redundancy management, while N = 5 represents quintuple-mode memory redundancy management. N can be specified in the compiler's XMR plugin.

[0132] For example, in some embodiments, the executable code corresponding to the target code obtained after compilation and instrumentation can also apply for a multi-module redundant memory management structure for managing N copies of memory during runtime. For example, when the executable code corresponding to the first API is running, it first applies for the multi-module redundant memory management structure and then applies for N copies of memory; when releasing, the executable code corresponding to the fourth API first releases the N copies of memory and then releases the multi-module redundant memory management structure.

[0133] For example, the three-module memory management structure and the five-module memory management structure shown in Figure 7. Applying for a multi-module redundant memory management structure requires reserving corresponding memory space to store the necessary information required for read / write operations on N memory blocks, thereby managing the N memory blocks. In different embodiments, the memory space reserved for the management structure may include the memory space occupied by the N memory blocks, or may not include the memory space occupied by the N memory blocks.

[0134] In contrast, ordinary memory variables without MMR memory management requirements (i.e., those without MMR preambles as shown in Figure 7) do not require compilation and instrumentation, but instead directly allocate a memory block. This allows compilation and instrumentation with preambles, while compilation and instrumentation without preambles are not, enabling the same code to be compatible with both high-reliability memory management requirements and non-high-reliability memory management requirements.

[0135] It should be noted that the solution provided in the embodiment of the present application can run in user mode or in kernel mode.

[0136] The source code in the embodiments of the present application may include business APP code and / or non-business code.

[0137] Furthermore, as shown in FIG8 , illustratively, the compilation instrumentation is further described by taking the source code in CC++ language as an example.

[0138] Figure 8 shows the changes in the business APP code (source code) and the compiler IR code before and after compilation and instrumentation. During the business APP code phase, the introduction "_tmr" (triple modular redundancy) was added. During the compilation phase, the compiler IR code was modified to call the multi-module redundant memory allocation function (first API) "_xmr malloc()", the multi-module redundant memory read function (third API) "call void@_xmr read()", and the multi-module redundant memory write function (second API) "_xmr write()". It should be noted that when the free() function appears in the source code, that is, the memory release interface, it is compiled to call the multi-module redundant memory release function (fourth API) "_xmr free()".

[0139] As shown in Figure 8, the compilation process can be divided into Frontend, Midend, and Backend processing, and compilation instrumentation can be implemented in the mid-end processing stage. Exemplarily, the compiler XMR plug-in, specifically the XMR Pass, is added to the Pass Pipeline. For example, in some embodiments, it can be added at the end of the Pass Pipeline. Here, pass represents a functional plug-in that may play an optimization role in the compilation process, and the Pass Pipeline is a plug-in sequence. For example, LLVM (Low Level Virtual Machine) is a framework system for building compilers. For specific compilation optimizations, LLVM requires a fixed set of Passes. A fixed set of Passes is called a PassPipeline. In the embodiment of the present application, the pipeline after compilation instrumentation is composed of Inline Pass, DCE Pass...XMR Pass. It should be noted that in other embodiments, the XMR Pass can also be added to other positions in the pipeline, not limited to being added to the end of the pipeline.

[0140] Optionally, you can set a compilation switch to control whether to start XMR Pass. If the switch is turned on, compilation instrumentation is performed. If the switch is turned off, compilation instrumentation is not performed.

[0141] It should be noted that, in order to recognize the introduction during the compilation process, it is also necessary to add introduction attributes in the source code analysis and recognition stage. In a compilation process, the source code analysis and recognition stage, i.e., the front-end processing process, can include three stages: lexical analysis, syntactic analysis, and semantic analysis, to obtain intermediate code. The source code is subjected to lexical analysis to obtain lexical terms, the lexical terms are subjected to syntactic analysis to obtain a syntax tree, and the syntax tree is subjected to semantic analysis to obtain intermediate code. In some embodiments of the present application, it is necessary to add attribute recognition for the introduction in at least one of the lexical analysis layer, the syntax analysis layer, and the semantic analysis layer. For example, if the introduction in the source code is "tmr_", it is necessary to add semantic recognition of the character "tmr_" in the source code analysis and recognition stage.

[0142] In some embodiments, the preamble only needs to be added when allocating memory for the target variable. After that, reading, writing, and releasing the target variable do not require the preamble. This requires adding attribute information about the target variable during the compilation process, for example, at at least one of the lexical analysis layer, the syntactic analysis layer, and the semantic analysis layer, so that the compiler can identify the variable as a target variable requiring multi-module redundant memory management.

[0143] After compilation and instrumentation, the target code is obtained. In some embodiments, the target code can be the IR code (intermediate representation) obtained after the "Midend" processing shown in Figure 8. The target code is then processed by the backend to obtain the machine code (executable code).

[0144] The compilation process of C / C++ can also be divided into multiple stages: preprocessing, compilation, assembly, and linking. In other embodiments, the target code can be the code after compilation and before assembly.

[0145] For Java language source code, the target code obtained after compilation and instrumentation is the code with the extension .class, that is, the Java bytecode file.

[0146] It should be noted that the product form corresponding to the method provided in the embodiment of the present application can be an application, a program upgrade package, a functional plug-in, etc., such as the functional plug-in TMR Pass shown in Figure 8, which is used to upgrade the software version and improve reliability.

[0147] In addition to implementing dynamic memory management, the method provided in the embodiment of the present application can also implement static memory management.

[0148] Static memory management is suitable when the modified memory variables are static or global variables. Static variables include static local variables and static global variables. Unlike dynamic memory management, static memory is centrally allocated in a program segment by the compiler. The operating system allocates this memory once when the binary program is loaded and releases it once when the program exits or the OS shuts down.

[0149] As shown in Figure 9, static memory management can be performed based on the system architecture shown in Figure 9, which includes a program loader or OS loader, a memory manager, and a compiler. The APP memory space is the memory space allocated to the APP by the memory manager.

[0150] Specifically, the static memory management method provided in the embodiment of the present application may include the following process:

[0151] S10, identifying the presence of a lead in the compilation object.

[0152] In static memory management, the introduction is used to modify static variables or global variables to indicate that the modified memory variable is the target variable for applying for multi-module redundant memory;

[0153] S20, compile and instrument the compiled object to obtain the target code.

[0154] When the executable code corresponding to the target code is run, it is used to apply for at least N memory corresponding to the target variable, where N ≥ 2 and is an integer.

[0155] In some embodiments, unlike dynamic memory management, the compilation instrumentation for the memory request interface and the memory release interface is as follows:

[0156] Memory request:

[0157] The compiler links the variable definitions of the specified compilation directives to the multi-mode data segments of the binary program (executable code). For example, see Figure 10, where there are specified multi-mode redundant directives (such as _tmr) in the compilation object, the variable c definition with the directive is linked to the multi-mode memory segments ".data_tmr1, .data_tmr2, .data_tmr3" (i.e., the multi-mode data segments) of the binary program; the variable a definition without a specified compilation directive is linked to the original data segment (such as .data) of the binary program.

[0158] Specifically, taking the three-mode as an example, the compiler identifies variable symbols with compilation directives such as "tmr" during the lexical analysis and syntax analysis stages, and stores them in the symbol table; three new multi-mode redundant data segments (such as .data_tmr1, .data_tmr2, and .data_tmr3) are added to store the variable data of each mode respectively.

[0159] In Figure 10, char a represents the character variable a, char c represents the character variable c, ELF Header represents the ELF file header, Program header represents the program header, .text represents text, data represents the data segment, and section header represents the segment header. Kernel data represents kernel data, stack represents the stack, heap represents the heap, Shared Libraries Memory Mapping represents the shared library memory mapping area, Load Segments.data represents loading segment data, and do_execve(), Search_binary_handler, load_elf_binary, and start_thread are all functions.

[0160] The program loader or the OS loader parses the multi-module redundant data segments in the binary program when the program or the OS is loaded, and uniformly applies for memory space for multiple copies of the multi-module redundant data segments.

[0161] Memory release:

[0162] When the program exits or the OS shuts down, the program loader releases multiple copies of the multi-module redundant data segments.

[0163] For a memory read interface with a memory variable (target variable) modified by a preamble as the object, for example, *p is the target variable and a=*p is the read interface, then the compilation instrumentation operation for the read interface is as follows:

[0164] Because *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer read access form (such as *p) into a call to the multi-module redundant memory read interface (such as __xmr_read) before compiling the code into an executable binary program.

[0165] The multi-module redundant memory read interface (such as __xmr_read) sequentially reads the contents of multiple copies of memory specified by the multi-module memory management structure, checks the consistency of the multiple copies, corrects any inconsistent copies, and returns the correct value from the multiple copies.

[0166] The compilation and instrumentation operations for the write interface (example * p = 10) are as follows:

[0167] Because *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer write access form (such as *p) into a call to the multi-module redundant memory write interface (such as __xmr_write) before compiling the code into an executable binary program.

[0168] The multi-module redundant memory write interface (such as __xmr_write) updates the value of each memory copy in sequence according to the multiple copies of memory specified by the multi-module memory management structure, checks the consistency of the multiple copies, corrects any inconsistent memory, and returns the value of the correct memory copy.

[0169] According to the above embodiments, in static memory management, compiling and instrumenting a compiled object to obtain target code may include at least one of the following:

[0170] Memory request: The definition of the target variable in the compiled object is linked to the multi-mode data segment of the binary program to obtain the executable code; the executable code is used to request N shares of memory corresponding to the target variable when it is loaded or loaded by the operating system.

[0171] Memory read: Modify the read interface with the target variable as the object in the compiled object to call the second API; the second API is a function that performs multi-module redundant memory read operations; the executable code corresponding to the second API is used to read at least the values ​​stored in N copies of memory during runtime.

[0172] Memory write: Modify the write operation with the target variable as the object in the compiled object to call a third API; the third API is a function that performs multi-module redundant memory write operations; when the executable code corresponding to the third API is run, it is used to write the value of the target variable into N copies of memory respectively.

[0173] Several specific embodiments are listed below.

[0174] As shown in FIG11 , in a specific embodiment, a TMR header is added based on the ptmalloc memory management structure, and a FatPointer (also known as a wide pointer) is used to implement TMR memory tracking. The specific implementation steps are as follows:

[0175] S11, identifying the lead in the compilation object. In this embodiment, the compilation object is C / C++ language source code, the target variable is *p, and the code line corresponding to the target variable (target code line) is: __xmr char*p=malloc(size), where "__xmr" is the lead, "char*p" is the definition of the target variable, and "malloc()" is the memory allocation interface.

[0176] The memory request interface "malloc()" is a POSIX-compatible memory request API. POSIX, or Portable Operating System Interface, is a general term for a series of interrelated standards that define APIs for running software on various UNIX operating systems. Its official name is IEEE Std 1003, and its international standard name is ISO / IEC 9945. The method provided in the embodiment of the present application compiles POSIX-compatible memory management interfaces such as memory request, release, read, and write, that is, it is compatible with the current ISO / IEC 9945 standard, that is, it implements multi-module redundant memory management without changing the memory management interface under the current standard. The related technology is not compatible with POSIX because it uses a new memory management interface in the source code.

[0177] It should be noted that the embodiments of the present application are mostly described using the ptmalloc memory manager as an example. In fact, the method provided in the embodiments of the present application can also be compatible with memory managers such as jemalloc and tcmalloc.

[0178] In this embodiment, the introduction is added before the target variable, so when identifying, the introduction can be identified first, and then the memory variable after the introduction can be determined as the target variable. Therefore, the modified memory variable needs to add a new attribute, which is used to indicate that the memory variable needs to be managed with multi-module redundant memory. Specifically, the attribute information about the target variable can be added in the source code analysis and identification stage during compilation, such as in at least one of the lexical analysis layer, the syntax analysis layer, and the semantic analysis layer, so that in the compilation process, other operations with the target variable as the object, such as releasing, reading and / or writing interfaces, can be identified as objects that need to be compiled and plugged in without adding a introduction, that is, the original ordinary function call is modified to a call to the second API, the third API, or the fourth API.

[0179] S12, perform compilation instrumentation on the compiled object to obtain the target code.

[0180] In this embodiment, compilation instrumentation is performed on the compilation object, which may be a compilation instrumentation operation performed on a memory management interface with the target variable as the object. The memory management interface includes at least one of a memory allocation interface, a memory read interface, a memory write interface, and a memory release interface. The compilation instrumentation may be specifically performed as follows:

[0181] Before the compiler compiles the compiled object (source code or intermediate code) into an executable binary program, the following process is added for the memory allocation interface with the multi-module redundant directive (for example, __xmr char*p=malloc(size)):

[0182] Preprocessing: Reserve memory space for the TMR management structure and apply for the TMR management structure. The TMR management structure is a new management structure based on the original ptmalloc management structure. For example, as shown in Figure 11, the TMR Header is a new TMR management structure used to manage multiple memory locations occupied by the target variable.

[0183] Reserving memory space for the TMR management structure can be implemented based on multiple existing memory reservation methods, such as reservation based on the mmeblock management mechanism, and can be reserved from the system's available physical memory or user-reserved memory.

[0184] The TMR management structure includes at least a TMR Header. Optionally, the TMR management structure may also include an mchunk Header and address spaces for applying for three memory shares.

[0185] Application: After requesting the TMR Header, three independent memory blocks are requested from the free queue. This embodiment uses triple-module redundant memory management as an example. For each target variable, three memory blocks are requested. For example, as shown in Figure 11, three memory blocks are requested: primary mchunk1, backup mchunk2, and backup mchunk3.

[0186] Allocation: After obtaining three independent memory blocks, the first addresses of the memory blocks are uniformly returned to the TMR management structure. Specifically, in this embodiment, the base addresses of backup mchunk2 and backup mchunk3 are returned to the TMR Header, where pTmr3 is a memory unit for storing the base address of backup mchunk3, and pTmr2 is a memory unit for storing the base address of backup mchunk2.

[0187] Return the wide pointer: The high bit of the fatpointer is used to store the base address of the main mchunk1 (pBase as shown in Figure 11), and the low bit is used to store the first pointer. A wide pointer is a pointer that occupies two bytes of a normal pointer, and a first pointer is an ordinary pointer that occupies half the number of bytes of a wide pointer. Exemplarily, the wide pointer in this embodiment occupies 64 bits (8 bytes) and the first pointer occupies 32 bits. The wide pointer fatpointer can be (pBase, p1), where p1 is the first pointer.

[0188] The first pointer points to the memory address in the main mchunk1 memory block used to store the value of the target variable. The base address is the starting address of the memory block, and the memory address pointed to by the first pointer is the address where the value of the target variable is actually stored.

[0189] In other embodiments, the high bit of the wide pointer can also be used to store the base address of the TMR header, that is, when applying for the management structure, the base address of the TMR header is returned as the high bit of the fat pointer, and the first pointer is used as the low bit of the fat pointer.

[0190] The memory address pointed to by the first pointer can be the address in the main memory block mchunk1 returned after the write operation is performed on the three memory blocks. The memory addresses used to store the values ​​of the target variables in the backup mchunk2 and backup mchunk3 do not need to be returned.

[0191] In this way, after the above operations, N copies of memory can be applied. When accessing the TMR memory through pointer read / write, the compiler inserts the stub function to find pBase, and then find the TMR header address. Then, three independent memory blocks are obtained in sequence and read / write operations are performed on them. The data consistency of the three copies of memory is compared, the correct data is obtained through arbitration, and the incorrect data is corrected.

[0192] Specifically, for example, the compilation and instrumentation operations for the memory read interface are as follows:

[0193] For the memory read interface in the compiled object, for example, a=*p, since *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer read access form, for example, *p, into the following process before compiling the code into an executable binary program:

[0194] Get the base address (pBase) of "main mchunk1" through the high bit of fatpointer, and get the first pointer (p1) of "main mchunk1" through the low bit.

[0195] Next, according to the base address pBase of the main memory block mchunk1, the base address of the TMR Header is obtained, and then the base addresses of "backup mchunk2" and "backup mchunk3" are obtained.

[0196] When applying for a memory management structure, the memory space required for the TMR Header is reserved, and the offset (first offset) of the base address of the main memory block mchunk1 relative to the TMR Header base address is specified. The first offset is a known constant, for example, a fixed value of m bytes. Therefore, when performing a read operation, the base address of the main memory block mchunk1 is obtained as pBase based on the high bit of the wide pointer. Then, the first offset is added or subtracted from pBase, for example, adding or subtracting m bytes, to obtain the TMR Header base address.

[0197] Then, based on pBase and p1, the pointers p1, p2, and p3 of the corresponding types of memory at the corresponding positions in "primary mchunk1", "backup mchunk2", and "backup mchunk3" are calculated. There are two specific calculation methods, as follows:

[0198] Method 1, p1 is the second offset:

[0199] As a feasible implementation method, the memory address pointed to by the first pointer p1 can be an offset address relative to pBase, that is, p1 represents the offset (second offset) relative to the main memory block mchunk1. Then, since the base addresses of the backup memory block mchunk2 and the backup memory block mchunk3 are stored in the TMR Header, after obtaining the base address of the TMR Header, the base address of the backup memory block mchunk2 (pTmr2) and the base address of the backup memory block mchunk3 (pTmr3) can be obtained. The base address of the backup memory block mchunk2 plus the second offset is the memory address corresponding to the second pointer, that is, the address for storing the value of the target variable. The base address of the backup memory block mchunk3 plus the second offset is the memory address corresponding to the third pointer, that is, the address for storing the value of the target variable.

[0200] Method 2: The second offset is the offset of p1 relative to pBase:

[0201] As another feasible implementation, the memory address pointed to by the first pointer p1 can be an absolute address. Then the second offset is the offset of p1 relative to the base address pBase of the main memory block mchunk1. First calculate the second offset of p1 relative to pBase. Since the base addresses of the backup memory block mchunk2 and the backup memory block mchunk3 are stored in the TMR Header, after obtaining the base address of the TMR Header, the base address of the backup memory block mchunk2 (pTmr2) and the base address of the backup memory block mchunk3 (pTmr3) can be obtained. The base address of the backup memory block mchunk2 plus the second offset is the memory address corresponding to the second pointer, that is, the address used to store the value of the target variable. The base address of the backup memory block mchunk3 plus the second offset is the memory address corresponding to the third pointer, that is, the address used to store the value of the target variable.

[0202] In this way, through the above method 1 or 2, the second pointer p2 and the third pointer p3 can be obtained. The data in the addresses p1, p2, and p3 are read and the data consistency of the three memories is compared. The correct data is obtained by arbitration and the wrong data is corrected.

[0203] For example, in Figure 12, the TMR Header is also used to store the values ​​of three memory blocks. For example, the three memory units uTmr3sum, uTmr2sum, and uTmr1sum are used to store the values ​​of backup mchunk3, backup mchunk2, and primary mchunk1, respectively, for quick comparison. After comparison, the correct values ​​can be written into the three memory blocks respectively.

[0204] Specifically, for example, the compilation and instrumentation operations for the memory write interface may be as follows:

[0205] For the memory write interface in the source code, for example, *p=10, since *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer write access form, for example, *p=10, into the following process before compiling the code into an executable binary program:

[0206] Get the base address (pBase) of "main mchunk1" through the high bit of fatpointer, and get the first pointer (p1) of "main mchunk1" through the low bit.

[0207] In the address pointed to by the first pointer P1, the value of the target variable is written, for example, "10". Then, according to the base address pBase of the main memory block mchunk1, the base address of the TMR Header is obtained, and then the base addresses of "backup mchunk2" and "backup mchunk3" are obtained.

[0208] The specific method of obtaining the base addresses of "standby mchunk2" and "standby mchunk3" based on pBase refers to the compilation and instrumentation operation of the read interface, which will not be repeated here.

[0209] Then, the base addresses of "standby mchunk2" and "standby mchunk3" and p1 are used to obtain the pointers p2 and p3 of the corresponding type of memory at the corresponding positions in "standby mchunk2" and "standby mchunk3". The specific method is the same as the above method 1 or method 2, which will not be repeated here.

[0210] Write the value of the target variable into the addresses pointed to by p2 and p3 respectively.

[0211] After writing, the data in the addresses p1, p2, and p3 can be read, and the data consistency of the three memories can be compared. The correct data can be obtained through arbitration and the incorrect data can be corrected.

[0212] For example, the compilation instrumentation operation for the memory release interface may be as follows:

[0213] For the memory release interface free(p) in the compiled object, since the input parameter p specifies a multi-module redundant directive when applying for memory, the compiler will convert the memory release interface into the following process before compiling the code into an executable binary program:

[0214] Release 3 memory blocks; release TMR Header.

[0215] In summary, a specific embodiment shown in Figure 11 first performs preprocessing, applies for memory space (size) to reserve the TMR management structure, and then applies for 3 memory blocks from the four-layer idle queue. The queue parallelism of the idle queue is twice the number of cores. After obtaining the 3 memory blocks, they are managed uniformly through the TMR Header. Then, the high bit of the fatpointer is used to store the base address pBase of the main memory block or the base address of the TMR Header, and the low bit is the traditional pointer (first pointer); when the first pointer accesses, the compiled plug-in function can find pBase to perform multi-mode comparison. When performing read and write operations, memory access can be made compatible with traditional heap memory access. First, during compilation, the pointer access operation is replaced with a read / write plug-in function (i.e., the second API and the third API). The read / write instrumentation function performs the following operations at runtime: It obtains pBase from the high bit of fatpointer and the pointer (p) to the corresponding memory type in primary memory block mchunk1 from the low bit. Using pBase, it obtains the base addresses of backup memory blocks mchunk2 and mchunk3. Based on pBase and p, it calculates pointers p1, p2, and p3 to the corresponding memory types at corresponding locations in primary memory blocks mchunk1, mchunk2, and mchunk3. It then performs a triple-module redundancy comparison and returns the results.

[0216] According to the description of the above specific embodiment, other embodiments can be summarized. In these embodiments, N copies of memory may include 1 main memory block and N-1 backup memory blocks. The target code obtained by compiling and inserting includes calling the first API. When the executable code corresponding to the first API is running, it can apply for the first multi-module redundant memory management structure, and then based on the first multi-module redundant management structure, apply for N copies of memory corresponding to the target variable, and return the base addresses corresponding to the N copies of memory respectively; the first multi-module redundant management structure includes at least an object header. The header is used to store at least the base addresses of N-1 backup memory blocks. In other embodiments, the first multi-module redundant management structure may include an object header and a first address space; applying for N copies of memory corresponding to the target variable is done within the first address space. For example, when applying for the first multi-module redundant management structure, the offset between the starting address of the first address space and the starting address of the header can be specified, and the starting address of the main memory block is the starting address of the first address space.

[0217] Then, a pointer used to access the target variable is defined as a wide pointer; the wide pointer is returned; the high bit of the wide pointer is used to store a first base address, and the low bit is used to store a first pointer; wherein the first base address is the base address of the main memory block mchunk1; the first pointer points to a memory address in the main memory block mchunk1 for storing the value of the target variable.

[0218] In the same embodiment or other embodiments, the target code obtained by compiling and inserting further includes calling a second API. When the executable code corresponding to the second API is running, based on the first base address pBase and the first pointer p1, the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks are determined; wherein the second base address is the base address of the header; the second pointer to the Nth pointer respectively point to the memory address for storing the value of the target variable in the N-1 backup memory blocks. The value of the target variable in each memory block can be accessed through the first pointer and the second pointer to the Nth pointer.

[0219] Among them, based on the first base address and the first pointer, the second base address and the second pointer to the Nth pointer corresponding to the N-1 spare memory blocks are determined. The second base address can be determined based on the first base address and the first offset; the first offset is the offset of the second base address relative to the first base address, and the first offset is a constant; then, according to the second base address, the base addresses corresponding to the N-1 spare memory blocks are read respectively; the second offset of the memory address pointed to by the first pointer relative to the first base address is determined; according to the base addresses and the second offsets corresponding to the N-1 spare memory blocks respectively, the second pointer to the Nth pointer are determined.

[0220] It should be noted that the base address of each backup memory block is stored starting from the starting address (i.e., base address) of the header. In some embodiments, the header is also used to store the N values ​​returned by the first pointer to the Nth pointer. The second API can also compare the N values ​​returned from the N copies of memory, determine the correct value through arbitration, and return it. It can also correct the faulty memory block, for example, by writing the correct value to the faulty memory block.

[0221] The specific embodiment listed above and other embodiments that can be derived therefrom add a TMR header based on the ptmalloc memory management structure, use FatPointer to implement TMR memory tracking, and implement business-insensitive TMR heap memory reading and writing through multi-module redundant computing plug-ins, supporting the mixed use of multi-granularity conventional heap memory and TMR heap memory.

[0222] Another example is shown below. As shown in Figure 12, in this example, fixed offsets are used to track TMR memory, and multi-module redundant read and write function stubs are used to implement business-insensitive TMR heap memory reading and writing. By replacing fat pointers with fixed offsets, pointer size multiplication is avoided, and compiler work is relatively simple. Specifically, the following process may be included:

[0223] S21, identifying the introduction in the compilation object.

[0224] For the recognition of the introduction, please refer to the embodiment corresponding to FIG11 , which will not be described in detail here.

[0225] S22, perform compilation instrumentation on the compilation object to obtain the target code.

[0226] For example, for each operation of the multi-module redundant memory application, release, read, and write functions based on the introduction, the specific implementation steps are as follows.

[0227] In the source code, when calling the POSIX-compatible memory request API, the corresponding memory variable definition, for example, adds the multi-module redundant lead __xmr before char*p, indicating that multi-module redundant memory needs to be requested with *p.

[0228] Before the compiler compiles the code into an executable binary program, it adds the following process to the memory allocation interface with the multi-module redundant directive, such as __xmr char*p=malloc(size).

[0229] Preprocessing: Reserve memory space for the TMR management structure and apply for the TMR management structure. As shown in Figure 12, the TMR management structure applied for in this embodiment includes three memory spaces with relatively fixed offsets and the same structure, which are mapped to the underlying memory pool respectively.

[0230] Application: Apply for three independent memory blocks from three independent memory pools at the bottom layer.

[0231] Allocation: Allocate 3 independent memory blocks.

[0232] Since the offsets between the main memory block mchunk1, the backup memory block mchunk2, and the backup memory block mchunk3 are known fixed offset values, it is only necessary to record the address of the main memory block mchunk1, and then add the known fixed offset value to the address to obtain the addresses of the other two independent memory blocks in sequence, and perform read / write operations on them, compare the data consistency of the three memories, arbitrate to obtain the correct data, and correct the erroneous data.

[0233] For the memory release interface, such as free(p), it is replaced by calling the fourth API to first release the three memories and then release the management structure.

[0234] For the memory read interface, for example, for a=*p, because *p specifies the multi-module redundant directive when applying for memory, the compiler will convert the pointer read access form (such as *p) into the following process before compiling the code into an executable binary program:

[0235] Since the offsets between the main memory block mchunk1, the backup memory block mchunk2, and the backup memory block mchunk3 are known fixed offset values, the address of the main memory block mchunk1 (p1) is obtained, and the main memory block mchunk1 address plus the known fixed offset value can be used to obtain the addresses of the remaining two independent memory blocks (p2, p3) in sequence.

[0236] Read the data in memory p1, p2, and p3 sequentially, compare the data consistency of the three memories, arbitrate the correct data, and correct the incorrect data. Return the correct value in the multiple memories.

[0237] The compilation method of the memory write interface (example *p=10) is similar to that of the memory read interface and will not be repeated here.

[0238] Based on the explanation of another embodiment above, multiple other embodiments can be summarized. In these embodiments, the target code obtained by compiling and inserting includes calling the first API; the first API applies for N copies of memory corresponding to the target variable; wherein the base address of the t-th memory block is fixedly offset relative to the base address of the t-1-th memory block; 2≤t≤N. That is, among the N copies of memory applied for, the offset between the base addresses of two adjacent memory blocks is a fixed value. In other embodiments, the first API can first apply for a second multi-module redundant memory management structure; the second multi-module redundant management structure includes a second address space; and N copies of memory can be applied for in the second address space.

[0239] In the same embodiment or other embodiments, N copies of memory include 1 main memory and N-1 backup memory blocks. The target code includes calling a second API; when the executable code corresponding to the second API is running, based on the first pointer and the offset of the fixed offset, the second pointer to the Nth pointer are determined respectively. The first pointer points to the memory address in the main memory block where the value of the target variable is stored. The memory address pointed to by the first pointer can be an offset address or an absolute address. The value of the target variable in each memory block can be read through the first pointer and the second pointer to the Nth pointer.

[0240] The embodiment corresponding to FIG12 and other embodiments derived therefrom replace wide pointers with fixed offsets to avoid doubling the pointer size, and the compiler work is relatively simple. However, since it is impossible to distinguish between TMR memory variables (target variables) and traditional memory variables (ordinary memory variables) at the binary code stage, all read and write operations require stubs.

[0241] Another example is shown below. As shown in Figure 13, in yet another example, fixed partitioning, virtual address separation, and compiler instrumentation are used to achieve service-insensitive TMR memory management. This example also replaces fat pointers with fixed offsets to avoid pointer size multiplication, making compiler work relatively simple. Virtual address separation distinguishes TMR memory areas from traditional memory areas, ensuring that only TMR memory read and write operations require instrumentation.

[0242] As shown in FIG13 , when applying for a management structure, you can apply for a TMR virtual memory partition (ie, a TMR virtual memory partition) and a traditional virtual memory partition, that is, apply for two independent memory spaces to achieve storage separation of target variables and ordinary memory variables.

[0243] The specific process may include the following:

[0244] S31, identifying the introduction in the compilation object.

[0245] For the recognition of the introduction, please refer to the embodiment corresponding to FIG11 , which will not be described in detail here.

[0246] S32, perform compilation instrumentation on the compilation object to obtain the target code.

[0247] For example, for each operation of the multi-module redundant memory application, release, read, and write functions based on the introduction, the specific implementation steps are as follows.

[0248] Before the compiler compiles the code into an executable binary program, it adds the following process to the memory allocation interface with the multi-module redundant directive, such as __xmr char*p=malloc(size).

[0249] Preprocessing: Apply for a TMR virtual memory partition (the first virtual memory area) and a traditional virtual memory partition (the second virtual memory area). The TMR virtual memory partition can be divided into multiple sub-areas, such as the primary 1 partition, the backup 2 partition, and the backup 3 partition. Within each sub-area, a corresponding management structure can be applied. For example, the management structure corresponding to the primary 1 partition includes header (pre_s, size, fd, dk), value (uTmr1sum), and memory block (primary mchunk1). The virtual memory partition is equivalent to specifying the memory address space range occupied by the target variable during the compilation process. When applying for a memory block, it is only applied within this memory space range. Ordinary memory variables can only be applied within another address space range, and the virtual addresses and physical addresses of the two address spaces do not overlap.

[0250] Application: Apply for three independent memory blocks from the three independent memory pools at the bottom of the TMR virtual memory partition mapping.

[0251] Allocation: Allocate 3 independent memory blocks.

[0252] Since the offsets between the main memory block mchunk1, the backup memory block mchunk2, and the backup memory block mchunk3 are known fixed offset values, it is only necessary to record the address of the main memory block mchunk1, and then add the known fixed offset value to the address to obtain the addresses of the other two independent memory blocks in sequence, and perform read / write operations on them, compare the data consistency of the three memories, arbitrate to obtain the correct data, and correct the erroneous data.

[0253] The difference from the embodiment corresponding to FIG12 is that this embodiment performs virtual memory partitioning to separate the TMR virtual memory from the ordinary virtual memory. The compilation of the read, write, and release interfaces may refer to the aforementioned embodiment and will not be repeated here.

[0254] According to the explanation of the above embodiment, other embodiments can be summarized. In these embodiments, by compiling and inserting, the target code includes calling the first API. The first API applies for a first virtual memory area and a second virtual memory area; the first virtual memory area is used to store the value of the target variable; the second virtual memory area is used to store the value of memory variables other than the target variable; within the address space occupied by the first virtual memory area, N copies of memory are applied, and among the N copies of memory, the base address of the tth copy of memory is fixedly offset relative to the base address of the t-1th copy of memory; 2≤t≤N. In one embodiment, the first API can first apply for a third multi-module redundant management structure, and the third multi-module redundant management structure includes a first virtual memory area and a second virtual memory area.

[0255] In another embodiment, fixed offsets are used to track TMR memory. Virtual address separation distinguishes between traditional and TMR memory areas, allowing only TMR memory read and write operations to be instrumented. Multi-module redundant read and write function instrumentation enables service-insensitive TMR heap memory read and write. On the one hand, replacing fat pointers with fixed offsets avoids pointer size multiplication, making compiler work relatively simple. On the other hand, virtual address separation distinguishes between TMR and traditional memory areas, requiring only TMR memory read and write operations to be instrumented.

[0256] The following is another example. As shown in Figure 14, this example can improve performance based on any one or a combination of the above examples. Read and / or write operations on target variables modified with preambles are replaced with OS inspections. This can significantly improve system performance in scenarios with large read / write volumes.

[0257] The following description is based on or expands upon the above embodiments. For each operation of the multi-module redundant memory application, release, read, and write functions based on the introduction, the specific implementation steps are as follows.

[0258] S41, identifying the introduction in the compilation object.

[0259] The identification of the introduction can adopt the method described in any of the above embodiments, which will not be repeated here.

[0260] S42, perform compilation instrumentation on the compilation object to obtain the target code.

[0261] For the compilation of the memory request interface, the method described in any of the above embodiments can be adopted. For example, in the source code, when it is necessary to call the POSIX-compatible memory request API to request multi-module redundant memory, a multi-module redundant preamble (such as __xmr) can be added before the variable definition of the memory. An example of the memory request interface after adding the preamble is: __xmr char*p=malloc(size). Then, before the compiler compiles the code into an executable binary program, it adds the following process to the memory request interface with the multi-module redundant preamble: reserve memory space for the TMR management structure and apply for the TMR management structure; apply for three independent memory blocks from the underlying memory pool; allocate three independent memory blocks.

[0262] In this embodiment, the following process may be used to compile the read interface:

[0263] Because *p specifies the multi-module redundant directive when applying for memory, the compiler converts the pointer read access form (such as *p) into the following process before compiling the code into an executable binary program:

[0264] The TMR read patrol thread is started during the OS startup phase.

[0265] The TMR read inspection thread triggers a TMR memory inspection when a predetermined condition is met. The predetermined condition can be a periodic trigger or a trigger based on a preset frequency, such as a patrol every hour or every 10 minutes. In other embodiments, a switch can be set for triggering the inspection, which can be controlled through user interaction.

[0266] The TMR read inspection thread reads each copy of the multi-module redundant memory in turn, compares the data consistency of each copy, arbitrates to obtain the correct data, and corrects the incorrect data.

[0267] Returns the correct memory value among multiple memories.

[0268] For the compilation of the write interface, you can refer to the compilation and instrumentation process of the read interface mentioned above. For example, you can use the following process:

[0269] The TMR write patrol thread is started during the OS startup phase.

[0270] The TMR write inspection thread triggers TMR memory inspection when the specified conditions are met.

[0271] The TMR write inspection thread writes the value of the target variable to each multi-module redundant memory in turn, compares the data consistency of each memory, arbitrates to obtain the correct data, and corrects the incorrect data.

[0272] In this embodiment, the compilation and instrumentation of the memory release interface can refer to any of the above embodiments, which will not be described in detail here.

[0273] Based on the explanation of the above embodiment, multiple other embodiments can be summarized. In these embodiments, compilation stubs are performed on the compiled object, including modifying the read interface and / or write interface of the compiled object with the target variable as the object to code for performing the following operations: pulling up a patrol thread; triggering the patrol thread, wherein the patrol thread is used to: write the value of the target variable into N memory blocks respectively; or read the value in N memory blocks corresponding to the target variable; compare the values ​​in the N memory blocks, obtain the correct value based on an arbitration strategy, and return it as the value of the target variable. The arbitration strategy can be to regard the value with the highest proportion as the correct value. For example, among five memory blocks, the values ​​of four memory blocks are consistent, all 11100101; the value of another memory block is 11100100, and the proportion of 11100101 is 80%. In this case, 11100101 is arbitrated as the correct value. 11100101 is then written to another memory block for correction.

[0274] In summary, the memory management method provided in the embodiment of the present application proposes to add a multi-module redundant preamble (such as __tmr) to the memory block to be applied for, indicating that the memory block is a multi-module memory block. The memory manager will apply for multiple copies of memory according to the preamble and manage them in a unified manner. In addition, a memory block read operation and / or write operation of the multi-module redundant preamble is proposed, and all or part of the compilation plug-in is performed according to the constraints of performance, reliability and specific scenarios. The plug-in function compares the consistency of the multi-module memory block and gives the arbitration result.

[0275] In this way, based on this method, shotgun reinforcement and modification of software codes of large-scale systems can be avoided, reliability reinforcement errors are invisible to the business, and the code quality, maintenance costs, and coordinated rapid iterative evolution of business codes in reliable and unreliable scenarios of large-scale software are guaranteed.

[0276] Furthermore, after testing, the memory management method provided in the embodiments of the present application has achieved positive technical effects in terms of reliability, robustness, and real-time performance, as follows:

[0277] Reliability: The system can be used normally under heavy load, high concurrency, and long-term operation.

[0278] Robustness: In abnormal situations such as single-particle upsets, it can achieve fault tolerance and ensure the normal operation of the system.

[0279] Real-time: Supports flexible and efficient memory allocation algorithms and strategies to speed up memory allocation and reading and writing.

[0280] An embodiment of the present application further provides a computer program product, comprising a program; the program including a preamble, the preamble being used to modify a target variable, the target variable being a memory variable for which multi-module redundant memory is to be allocated. The target code corresponding to the program is used to allocate at least N memory shares corresponding to the target variable; the target code includes code obtained by compiling and instrumenting the program; N is an integer greater than or equal to 2.

[0281] It should be noted that in some embodiments, the compilation process for different languages ​​is different, and the target code can be an intermediate code or an executable code (binary code). For example, after the Java language-based source code is compiled and instrumented, the target code can be a code in the .class format or the .dex format; after the C / C++ language-based source code is compiled and instrumented, the target code can be a code in the .i format, the .s format, the .exe format, or the .out format. In the target code, there will be at least one line of code corresponding to the memory request interface. Here, the memory request interface is a memory request interface with a memory variable modified by a guide as the object.

[0282] The present application also provides a computer program product, which includes a program that, when executed by an electronic device, enables the electronic device to implement the method described in any of the above embodiments. For example, the program product can be an application program, or an upgrade package or functional plug-in for upgrading the application program.

[0283] An embodiment of the present application also provides an electronic device, which includes: one or more processors; a memory; at least one application; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions, which, when executed by the electronic device, enable the electronic device to execute a method as described in any of the above embodiments.

[0284] Specifically, the electronic device may be a server or server cluster that provides operator sequence optimization services. Referring to FIG15 , the hardware structure of the electronic device may include: a processor, a memory, and a chipset.

[0285] Processor, the core that handles all computing tasks and requests, including at least the CPU.

[0286] Storage: This includes memory and hard disk. The larger the capacity, the more requests and files can be processed simultaneously.

[0287] Chipset: Includes the northbridge chip and the southbridge chip, which connect various I / O devices. The northbridge chip connects to the CPU, memory, and PCI bus, while the southbridge chip connects to hard drives, network devices, and other I / O devices.

[0288] I / O bus: Connects various I / O devices, such as network cards and USBs. The greater the server's I / O bus bandwidth, the more requests it can handle. I / O devices: These include network cards and USBs. Network cards are the primary device connecting the server to the external network, and their speed and performance directly impact the server's response and transmission speeds.

[0289] Power supply: Provides stable power to the server to ensure normal operation of the server.

[0290] Chassis: The outer shell of the server hardware, protecting it from dust, vibration, and temperature.

[0291] Exemplarily, a processor may include one or more processing units, for example, a neural-network processing unit (NPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a digital signal processor (DSP), a baseband processor, etc. The different processing units may be independent devices or integrated into one or more processors. The controller may generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0292] The memory can be used to store computer executable program code, which includes instructions. The internal memory may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, at least one application required for a function, etc. The data storage area can store data (such as input data, output data) created during the use of the electronic device. In addition, the internal memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor executes various functional applications and data processing of the electronic device by running instructions stored in the internal memory and / or instructions stored in a memory provided in the processor.

[0293] Alternatively, the electronic device may be a terminal device with certain computing capabilities, such as a mobile phone, a personal computer (PC) (e.g., a laptop), a tablet PC, a wearable electronic device, etc. The terminal device may include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charging management module, a power management module, a battery, etc.

[0294] It should be understood that the structure illustrated in the embodiment of the present invention is merely an example and does not limit the electronic device. The electronic device in the embodiment of the present application may include more or fewer components than shown, or combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0295] An embodiment of the present application further provides a storage medium including computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method described in any of the above embodiments.

[0296] An embodiment of the present application also provides a chip system, including a communication interface for inputting and / or outputting data; and a processor for executing a computer executable program so that a device equipped with the chip system executes a method as described in any of the above embodiments.

[0297] It should be noted that the solutions provided in the embodiments of the present application include any one or more of the memory management methods, devices, electronic devices and storage media, or may also be other forms of software products, hardware products or virtual service products obtained based on the technical concepts of the methods described in the specification of this application.

[0298] In the description of the device in the embodiment of the present application, various modules for implementing the method process functions are constructed in the device. The division of modules is merely a division of logical functions. When implementing the embodiment of the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0299] Specifically, in actual implementation, each functional module can be fully or partially integrated into one physical entity, or physically separated. Moreover, these modules can all be implemented in the form of software called through processing elements; or all can be implemented in the form of hardware; or some modules can be implemented in the form of software called through processing elements, and some modules can be implemented in the form of hardware. For example, the detection module can be a separately established processing element, or it can be integrated into a chip of an electronic device. The implementation of other modules is similar. In addition, these modules can all or partly be integrated together, or they can be implemented independently. During the implementation process, each step of the above method or each of the above modules can be completed by the hardware integrated logic circuit in the processor element or by instructions in the form of software.

[0300] For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0301] Specifically, in one embodiment of the present application, the above-mentioned one or more computer programs are stored in the above-mentioned memory, and the above-mentioned one or more computer programs include instructions. When the above-mentioned instructions are executed by the above-mentioned device, the above-mentioned device executes the method steps described in the embodiment of the present application.

[0302] Specifically, in one embodiment of the present application, the processor of the electronic device may be a SOC, which may include a central processing unit (CPU) and may further include other types of processors, such as a graphics processing unit (GPU). Specifically, in one embodiment of the present application, the processor of the electronic device may be a PWM control chip.

[0303] Specifically, in one embodiment of the present application, the processor involved may include, for example, a CPU, a DSP, a microcontroller, or a digital signal processor, and may also include a GPU, an embedded neural network processor (NPU), and an image signal processor (ISP). The processor may also include necessary hardware accelerators or logic processing hardware circuits, such as ASICs, or one or more integrated circuits for controlling the execution of the program of the technical solution of the present application. In addition, the processor may have the function of operating one or more software programs, and the software programs may be stored in a storage medium.

[0304] Specifically, in one embodiment of the present application, the memory of the electronic device may be a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any computer-readable medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer.

[0305] Specifically, in one embodiment of the present application, the processor and the memory may be combined into a processing device, or more commonly, they may be independent components, with the processor being configured to execute program code stored in the memory to implement the method described in the embodiment of the present application. In a specific implementation, the memory may also be integrated into the processor or independent of the processor.

[0306] Furthermore, the devices, apparatuses, and modules described in the embodiments of the present application may be implemented by computer chips or entities, or by products having certain functions.

[0307] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, apparatus, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0308] In the several embodiments provided in this application, if any function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of this application.

[0309] The embodiment description in this application is described with reference to the flow chart and / or block diagram according to the method, equipment (device) and computer program product of embodiment of the present application.It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized by computer program instructions.These computer program instructions can be provided to the processor of general-purpose computer, special-purpose computer, embedded processing machine or other programmable data processing equipment to produce a machine, so that the instruction executed by the processor of computer or other programmable data processing equipment produces the device for realizing the function specified in one flow chart flow chart or multiple flow charts and / or one block or multiple blocks of block diagram.

[0310] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0311] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0312] It should also be noted that, in the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. Among them, A and B can be singular or plural. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c or a and b and c, where a, b, c can be single or multiple.

[0313] In the embodiments of the present application, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, commodity, or apparatus comprising the element.

[0314] The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0315] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the partial description of the method embodiments.

[0316] Those skilled in the art will appreciate that the various units and algorithm steps described in the embodiments of the present application can be implemented using a combination of electronic hardware, computer software, and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0317] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices, apparatuses and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0318] The above description is merely a specific embodiment of the present application. Any person skilled in the art may easily conceive of variations or substitutions within the technical scope disclosed in this application, and such variations or substitutions shall be within the scope of protection of this application. The scope of protection of this application shall be subject to the scope of protection of the claims.

Claims

1. A memory management method, characterized in that: The method comprises: Recognize that there is a preamble in the compilation object; the preamble is used to modify a target variable, and the target variable is a memory variable for which a multi-mode redundant memory needs to be applied; Compile and insert the compiled object to obtain the target code; when the executable code corresponding to the target code is run, it is used to apply for at least N memory corresponding to the target variable, where N is greater than or equal to 2 and is an integer.

2. The method according to claim 1, characterized in that Performing compilation instrumentation on the compilation object includes: The memory application interface with the target variable as the object in the compiled object is modified to call the first API; the first API is a multi-mode redundant memory application function; the multi-mode redundant memory application function is used to apply for at least N copies of memory corresponding to the target variable.

3. The method according to claim 1 or 2, characterized in that Performing compilation instrumentation on the compilation object includes: The read interface with the target variable as the object in the compiled object is modified to call the second API; the second API is a multi-mode redundant memory read function; the multi-mode redundant memory read function is at least used to read the values ​​stored in the N copies of memory respectively.

4. The method according to any one of claims 1 to 3, characterized in that Performing compilation instrumentation on the compilation object includes: The write interface in the compiled object with the target variable as the object is modified to call a third API; the third API is a multi-module redundant memory write function; the multi-module redundant memory write function is at least used to write the value of the target variable into the N copies of memory respectively.

5. The method according to any one of claims 1 to 4, characterized in that Performing compilation instrumentation on the compilation object includes: The memory release interface with the target variable as the object in the compiled object is modified to call the fourth API; the fourth API is a multi-module redundant memory release function; the multi-module redundant memory release function is used to release at least the N copies of memory.

6. The method according to claim 5, characterized in that The executable code corresponding to the target code is also used to apply for a multi-module redundant memory management structure when running; the multi-module redundant memory management structure is used to manage the N copies of memory; The multi-module redundant memory release function is used to release the N copies of memory and the multi-module redundant memory management structure.

7. The method according to any one of claims 1 to 6, characterized in that Identify the presence of preambles in the compiled object, including: It is identified that in the compiled object, the preamble exists in the code line corresponding to the target variable.

8. The method according to any one of claims 1 to 7, characterized in that The N memory blocks include 1 main memory block and N-1 backup memory blocks; The target code includes calling a first API; the first API is used to perform the following operations: Applying for a multi-module redundant memory management structure; the multi-module redundant management structure includes an object header; the header is used to store at least the base addresses of the N-1 spare memory blocks; Apply for N memory copies corresponding to the target variable, and return the base addresses corresponding to the N memory copies respectively; Define a pointer used to access the target variable as a wide pointer; Return a wide pointer; the high bit of the wide pointer is used to store the first base address, and the low bit is used to store the first pointer; wherein the first base address is the base address of the main memory block; the first pointer points to the memory address in the main memory block used to store the value of the target variable.

9. The method according to claim 8, characterized in that The target code includes calling a second API; the second API is used to perform the following operations: Based on the first base address and the first pointer, determine the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks; wherein the second base address is the base address of the header; the second pointer to the Nth pointer respectively point to the memory addresses in the N-1 backup memory blocks for storing the value of the target variable; Read the values ​​in the memory addresses pointed to by the first pointer, the second pointer to the Nth pointer respectively.

10. The method according to any one of claims 1 to 7, characterized in that The target code includes calling a first API; the first API is used to perform the following operations: Apply for N copies of memory corresponding to the target variable; wherein the base address of the t-th copy of memory is fixedly offset relative to the base address of the t-1-th copy of memory; 2≤t≤N.

11. The method according to any one of claims 1 to 10, characterized in that Performing compilation instrumentation on the compilation object includes: The read interface and / or write interface of the compiled object with the target variable as the object is modified into a code for performing the following operations: Pull up the inspection thread; Trigger the inspection thread, which is used to: Writing the values ​​of the target variables into the N copies of memory respectively; or reading the values ​​of the N copies of memory corresponding to the target variables; Compare the values ​​in the N memories, obtain the correct value based on the arbitration strategy, and return it as the value of the target variable.

12. The method according to any one of claims 1 to 11, characterized in that When the target variable is a static variable or a global variable, performing compilation stubs on the compiled object to obtain the target code includes: The definition of the target variable in the compiled object is linked to the multi-mode data segment of the binary program to obtain executable code; the executable code is used to apply for N copies of memory corresponding to the target variable when it is loaded or loaded by the operating system.

13. A memory management device, characterized in that: The device comprises: A preamble recognition module is used to recognize that a preamble exists in a compilation object; the preamble is used to modify a target variable, and the target variable is a memory variable that needs to apply for a multi-module redundant memory; The compiling and plugging module is used to compile and plug the compiled object to obtain the target code; when the executable code corresponding to the target code is run, it is used to apply for N memory corresponding to the target variable at least, where N≥2 and is an integer.

14. The device according to claim 13, characterized in that The compilation stub module is specifically used to modify the memory application interface in the compilation object with the target variable as the object to call the first API; the first API is a multi-mode redundant memory application function; the multi-mode redundant memory application function is at least used to apply for N copies of memory corresponding to the target variable.

15. The device according to claim 13 or 14, characterized in that The compilation stub module is specifically used to modify the read interface of the compiled object with the target variable as the object to call the second API; the second API is a multi-module redundant memory read function; The multi-module redundant memory read function is at least used to read the values ​​respectively stored in the N copies of memory.

16. The device according to any one of claims 13 to 15, characterized in that The compilation stub module is specifically used to modify the write interface in the compilation object with the target variable as the object to call a third API; the third API is a multi-module redundant memory write function; the multi-module redundant memory write function is at least used to write the value of the target variable into the N copies of memory respectively.

17. The device according to any one of claims 13 to 16, characterized in that The compilation stub module is specifically used to modify the memory release interface in the compilation object with the target variable as the object to call the fourth API; the fourth API is a multi-module redundant memory release function; the multi-module redundant memory release function is at least used to release the N copies of memory.

18. The device according to any one of claims 13 to 17, characterized in that The N memory blocks include 1 main memory block and N-1 backup memory blocks; The target code includes calling a first API; the first API is used to perform the following operations: Applying for a multi-module redundant memory management structure; the multi-module redundant management structure includes an object header; the header is used to store at least the base addresses of the N-1 spare memory blocks; Apply for N memory copies corresponding to the target variable, and return the base addresses corresponding to the N memory copies respectively; Define a pointer used to access the target variable as a wide pointer; Returns a wide pointer; the high bit of the wide pointer is used to store the first base address, and the low bit is used to store the first pointer; wherein the first base address is the base address of the main memory block; the first pointer points to the memory in the main memory block for storing the value of the target variable address.

19. The device according to claim 18, characterized in that The target code includes calling a second API; the second API is used to perform the following operations: Based on the first base address and the first pointer, determine the second base address and the second pointer to the Nth pointer corresponding to the N-1 backup memory blocks; wherein the second base address is the base address of the header; the second pointer to the Nth pointer respectively point to the memory addresses in the N-1 backup memory blocks for storing the value of the target variable; Read the values ​​in the memory addresses pointed to by the first pointer, the second pointer to the Nth pointer respectively.

20. The device according to any one of claims 13 to 17, characterized in that The target code includes calling a first API; the first API is used to perform the following operations: Apply for N copies of memory corresponding to the target variable; wherein the base address of the t-th copy of memory is fixedly offset relative to the base address of the t-1-th copy of memory; 2≤t≤N.

21. The device according to any one of claims 13 to 20, characterized in that Performing compilation instrumentation on the compilation object includes: The read interface and / or write interface of the compiled object with the target variable as the object is modified into a code for performing the following operations: Pull up the inspection thread; Trigger the inspection thread, which is used to: Writing the values ​​of the target variables into the N copies of memory respectively; or reading the values ​​of the N copies of memory corresponding to the target variables; Compare the values ​​in the N memories, obtain the correct value based on the arbitration strategy, and return it as the value of the target variable.

22. The device according to any one of claims 13 to 21, characterized in that When the target variable is a static variable or a global variable, performing compilation stubs on the compiled object to obtain the target code includes: The definition of the target variable in the compiled object is linked to the multi-mode data segment of the binary program to obtain executable code; the executable code is used to apply for N copies of memory corresponding to the target variable when it is loaded or loaded by the operating system.

23. An electronic device, characterized in that: The electronic device comprises: One or more processors; a memory; at least one application; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions that, when executed by the electronic device, cause the electronic device to perform a method as described in any one of claims 1 to 12.

24. A storage medium, characterized in that The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method as claimed in any one of claims 1 to 12.

Images