Memory manager power failure recovery method and electronic devices

Abstract

This application discloses a memory manager power-off recovery method and electronic device, relating to the computer field. It achieves exclusive access to memory resources by initiating the process with a persistent trigger signal and combining it with a global mutex lock, ensuring the consistency of core data acquisition. The acquired data is structured and written to a dump file to construct a verifiable persistent carrier. During power-off recovery, the verification results of the dump file are used as a prerequisite to extract data and complete state reconstruction. This solves the technical problems of traditional power-off recovery, such as memory data acquisition being susceptible to concurrent interference, insufficient reliability of dump data, and low accuracy of the recovery process. It provides a structured, highly reliable persistent data source for memory manager power-off recovery, achieving accurate reconstruction of virtual memory regions, free lists, and allocated physical pages, ensuring the integrity of memory data and the normal operation of the memory manager after a power outage.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for power-off recovery of a memory manager and an electronic device. Background Technology

[0002] The power loss recovery capability of a memory manager directly affects the normal operation and data integrity after a system restart. In related technologies, memory manager power loss recovery solutions typically revolve around two core aspects: memory data persistence and recovery. The execution process generally includes: acquiring memory-related data and triggering persistence operations; creating a storage file and writing the data to memory; reading the data from the storage file during the power loss recovery phase; and reconstructing the memory management state based on the read data.

[0003] The key technical problem with the relevant memory manager power-off recovery solution is that the validity verification mechanism of the dump file is imperfect, and the correlation logic of each data item in the memory data dumping and recovery process is unclear. This makes it impossible to accurately verify the validity of the dump file during power-off recovery, and thus impossible to accurately reconstruct the state of the free list and allocated physical pages. Ultimately, this affects the reliability of the recovery result, and may even cause data loss or system abnormalities. Summary of the Invention

[0004] This application provides a method and electronic device for power-off recovery of a memory manager to solve the problem that the unclear correlation logic between memory data dumping and recovery in related technologies leads to the inability to accurately reconstruct data during power-off recovery.

[0005] This application provides a method for power-off recovery of a memory manager, including:

[0006] Acquire the persistence trigger signal and the global mutex lock of the memory manager. The persistence trigger signal is used to initiate the persistent storage of data information in the memory manager.

[0007] Under the exclusive access control of the global mutex lock, the data information stored in the memory manager is collected based on the persistent trigger signal. The data information includes the description information of the virtual memory region, the starting page frame number and memory level of the free block in the free list, and the starting virtual address and data content of the allocated physical page.

[0008] A dump file is created based on the data information, and the starting page frame number, memory level, starting virtual address, and data content of the free block are processed according to the preset processing rules to obtain the processed data information. The processed data information and description information are then written into the dump file.

[0009] In the event of a power outage recovery of the memory manager, the file header of the dump file is read and the dump file is verified based on preset verification rules and the file header to obtain the verification result;

[0010] Based on the verification results and dump files, the virtual memory regions, free lists, and allocated physical pages of the memory manager are reconstructed to restore the data information of the memory manager.

[0011] This application also provides a memory manager power-off recovery device, including:

[0012] The acquisition module is used to acquire the persistence trigger signal and the global mutex lock of the memory manager. The persistence trigger signal is used to initiate the persistent storage of data information in the memory manager.

[0013] The acquisition module is also used to acquire data information stored in the memory manager based on persistent trigger signals under the exclusive access control of the global mutex lock. The data information includes description information of the virtual memory region, the starting page frame number and memory level of the free block in the free list, and the starting virtual address and data content of the allocated physical page.

[0014] The creation module is used to create a dump file based on the data information, and to process the starting page frame number and memory level, starting virtual address and data content of the free block according to the preset processing rules to obtain the processed data information, and write the processed data information and description information into the dump file;

[0015] The verification module is used to read the file header of the dump file and verify the dump file based on preset verification rules and the file header in the event of a power failure and recovery of the memory manager, so as to obtain the verification result.

[0016] The recovery module is used to reconstruct the virtual memory regions, free lists, and allocated physical pages of the memory manager based on the verification results and dump files, in order to recover the data information of the memory manager.

[0017] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described memory manager power-off recovery methods when executing the computer program.

[0018] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described memory manager power-off recovery methods.

[0019] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described memory manager power-off recovery methods.

[0020] The memory manager power-off recovery method and electronic device provided in this application solve the technical problems of unreliable dump file validity and inaccurate memory state reconstruction in related technologies by constructing a dump file validity verification mechanism and accurately restoring the memory state according to the logical link of verification and reconstruction during recovery. This achieves the technical effect of improving the reliability of memory manager power-off recovery, ensuring data integrity and stable operation after system restart. Attached Figure Description

[0021] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram illustrating an application scenario of the memory manager power-off recovery method provided in this application embodiment;

[0023] Figure 2 A flowchart illustrating the power-off recovery method for a memory manager provided in an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of the structure of the memory manager power-off recovery device provided in the embodiments of this application;

[0025] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0027] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0028] To address the technical challenges of verifying the validity of dump files and accurately reconstructing memory states during power-off recovery of the memory manager, a complete technical chain is established, encompassing data acquisition, verification-based dumping, and verification-based recovery, to achieve reliable recovery. First, a global mutex lock ensures the consistency of critical memory data acquisition. Then, a dump file is created, and the validity of the dump file header is verified first during the recovery phase. Next, the free list and allocated physical pages are reconstructed, and abnormal data is identified and processed synchronously through verification and comparison. Ultimately, accurate restoration of the memory state is achieved, improving the reliability and stability of power-off recovery.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] This section describes the specific application environment architecture or hardware architecture that the execution of the memory manager's power-off recovery method depends on. (References) Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the memory manager power-off recovery method provided in this application embodiment, such as... Figure 1 As shown, it includes: terminal 101 and server 102.

[0031] Terminal 101 runs business applications and has a built-in memory manager component to monitor the status of virtual memory regions, free lists, and allocated physical pages in real time. Upon detecting a power outage warning signal or reaching a preset persistence period, it triggers a local persistence process, collects key memory data, and generates a dump file. Simultaneously, it can upload the dump file to server 102 for off-site backup. After a power outage and restart, it initiates a recovery request and performs memory state reconstruction operations based on the dump file sent locally or from the server. Server 102 receives the dump file uploaded by terminal 101 and performs encrypted storage and version management. After a power outage and restart, it receives the recovery request from terminal 101, sends the corresponding dump file, and collaborates with terminal 101 to verify the legality of the dump file. It also records the recovery process data and status information of terminal 101, providing data support for subsequent operation and maintenance analysis.

[0032] Figure 2 This is a flowchart illustrating the power-off recovery method for a memory manager provided in an embodiment of this application, as shown below. Figure 2 As shown, an embodiment of this application provides a method for power-off recovery of a memory manager. The method is described in detail below:

[0033] Step S201: Obtain the persistence trigger signal and the global mutex lock of the memory manager. The persistence trigger signal is used to initiate the persistent storage of data information in the memory manager.

[0034] Specifically, the acquisition of persistence trigger signals is based on preset triggering mechanisms (such as periodic triggering or event triggering); a global mutex lock is a synchronization mechanism used to achieve mutual exclusion access to resources between multiple threads. Its acquisition is based on the principle of mutual exclusion synchronization, locking the core resource access permissions of the memory manager to achieve ordered access to memory resources by multiple threads. The trigger signal is used to initiate the subsequent memory data persistence process, clarifying the execution timing of the persistence operation; the global mutex lock is used to ensure that memory resources are not modified by other concurrent operations during subsequent memory data acquisition, ensuring the consistency and integrity of the acquired data.

[0035] Step S202: Under the exclusive access control of the global mutex lock, collect the data information stored in the memory manager based on the persistent trigger signal. The data information includes the description information of the virtual memory region, the starting page frame number and memory level of the free block in the free list, and the starting virtual address and data content of the allocated physical page.

[0036] Specifically, based on the resource exclusive access control mechanism of mutex locks, a global mutex lock restricts the core data area of ​​the memory manager to be accessible only to the current data acquisition thread within a specified time period, blocking concurrent read, write, and modification operations of other threads on the target data. A persistent trigger signal is used as the start instruction for the acquisition process. Under the protection of the lock mechanism, the virtual memory area description information, the start page frame number and memory level of the free block in the free list, the start virtual address and data content of the allocated physical page generated during the operation of the memory manager are extracted in a targeted manner, ensuring that the acquisition process is strongly correlated with the trigger instruction and that the data extraction process is not interfered with by external operations.

[0037] The system reads relevant information through the interface provided by the memory manager. This information includes: the virtual memory region, which is the virtual address space region allocated by the operating system for each process; the free list, a linked list built in hierarchical order according to memory block size to store free memory blocks; allocated physical pages, which are physical memory pages allocated to processes; and the page frame number, a unique identifier for a physical memory page in physical memory. By collecting core state data during the memory manager's operation, comprehensive and accurate data support is provided for the subsequent construction of the dump file, avoiding incomplete recovery due to data loss.

[0038] Step S203: Create a dump file based on the data information, and process the start page frame number, memory level, start virtual address and data content of the free block according to the preset processing rules to obtain the processed data information, and write the processed data information and description information into the dump file.

[0039] Specifically, for the starting page frame number and memory level of the free block in the free list, a metadata array with a fixed format is generated through array encoding to achieve structured storage of free memory resource information; for the starting virtual address and data content of the allocated physical page, the address, data and check value are bound through a verification algorithm to generate a cyclic redundancy check mapping table array and establish a data integrity verification association; a dump file is created simultaneously as a data carrier, and the description information of the virtual memory region and the above two types of structured data information are written into the dump file according to a preset storage format to construct a persistent data set with integrity verification capabilities.

[0040] Step S204: In the case of power failure recovery of the memory manager, read the file header of the dump file and verify the dump file based on the preset verification rules and the file header to obtain the verification result.

[0041] Specifically, the file system-based reading mechanism reads the file header information according to the structure specifications of the dump file. The read magic number version data is compared with a preset standard value. Simultaneously, the checksum values ​​of the core fields in the file header (excluding the checksum field) are recalculated using the same hash algorithm and compared with the checksum values ​​in the file header. If both match, the verification passes; otherwise, the verification fails. This preliminary verification of the dump file's legality and integrity filters out invalid, tampered, or version-mismatched dump files, preventing recovery operations from being performed on erroneous files.

[0042] Step S205: Based on the verification results and dump file, reconstruct the virtual memory region, free list, and allocated physical pages of the memory manager to restore the data information of the memory manager.

[0043] Specifically, the virtual address space is re-partitioned based on the description information, and the association between processes and virtual addresses is established. Based on the starting page frame number and memory level information of the free blocks in the metadata array, the free blocks are reorganized according to the memory level classification rules, and a free linked list is constructed. The physical pages are located based on the starting virtual address and page frame number information in the cyclic redundancy check mapping table array. After verifying data integrity with the check information, reconstruction is completed. Based on the verified dump data, the core operating state of the memory manager is gradually restored, including virtual memory address mapping, free memory block management, and data recovery of allocated physical pages. This ensures the normal operation of the memory manager, accurately restoring it from an abnormal state after power failure to a normal operating state. This guarantees that applications relying on the memory manager can restart and run normally, restoring the normal functionality of the system.

[0044] The memory manager power-off recovery method provided in this invention achieves reliable persistence and accurate recovery of memory data by constructing a complete process of signal triggering, mutual exclusion acquisition, verification dumping, and verification recovery. It ensures the complete preservation of memory data before power failure, and ensures the accuracy of recovered data through multiple verification mechanisms. This effectively improves the reliability, stability, and efficiency of memory manager power-off recovery, and ensures that the system can quickly resume normal operation after a power failure and restart.

[0045] This embodiment details the process described in the above embodiment of creating a dump file based on data information, processing the start page frame number and memory level of the free block, the start virtual address and data content according to preset processing rules to obtain processed data information, and writing the processed data information and description information into the dump file. The specific implementation of this process includes the following steps:

[0046] Step a1: Create a dump file, populate the header core field of the dump file according to the description information and the preset magic number version data, and set the verification field in the header core field to the preset initial state.

[0047] Specifically, a dump file is a file used to store critical data in memory to enable power outage recovery. The creation of a dump file follows the file creation specifications of the file system. The filling of the core fields in the file header is based on the preset file header structure definition. The magic number version data is specific data used to identify the legality and version information of the file. The verification field is a field used to store the data integrity verification result. Setting it to the preset initial state is to reserve field space for subsequent calculation of verification values ​​and ensure the accuracy of verification calculation.

[0048] By creating a dump file, a persistent storage medium for in-memory data is provided. The core fields of the file header are filled to construct the basic identification and structural information of the dump file, clarifying its ownership and version. Verification fields are set to a preset initial state to prepare for subsequent integrity checks. A standardized dump file structure is generated, giving the dump file basic identification attributes, facilitating rapid identification of file legitimacy and version matching during the subsequent recovery phase, while ensuring the normal execution of subsequent verification calculations.

[0049] Step a2: Analyze the data content of the core header fields (excluding the verification field) using a preset hash algorithm, obtain the field verification values, and backfill them to form the file header, which is then written to the starting position of the dump file.

[0050] Specifically, the preset hash algorithm maps data of arbitrary length to a fixed-length hash value through specific mathematical operations. The preset hash algorithm is used to calculate the core fields of the file header (excluding the checksum field). The resulting hash value uniquely represents the integrity of the field data. After backfilling, a complete file header is formed and then written to the beginning of the dump file according to the file system's writing rules. Integrity verification of the file header data is achieved by calculating and backfilling the checksum. Writing the complete file header to a specified location ensures the standardized storage of the file header information, giving the file header integrity verification capabilities. This effectively detects whether the file header has been tampered with or damaged, ensuring the effectiveness of file header verification during subsequent recovery phases and improving the reliability of the dump file.

[0051] Step a3: Based on preset processing rules, perform structured processing on the starting page frame number and memory level of the free block to generate a metadata array.

[0052] Specifically, the metadata array is an array that stores structured information related to free blocks in the memory hierarchy. It is structured by organizing the discrete free block start page frame number and memory hierarchy information in a preset format.

[0053] Step a4: Based on preset processing rules, perform structured processing on the starting virtual address and data content to generate a cyclic redundancy check mapping table array.

[0054] Specifically, the Cyclic Redundancy Check (CRC) mapping table array is a structured array that stores the check information of allocated physical pages and their associated address information. CRC is a verification method that uses polynomial division to detect data transmission or storage errors. It calculates the check value of the allocated physical page data using the CRC algorithm, and then associates the check value with the starting virtual address in a preset format to form an array. By transforming discrete memory free block information and allocated physical page information into a structured data array, it achieves standardized and ordered storage of memory data, facilitating rapid reading and parsing during the subsequent recovery phase. This effectively improves the organization efficiency and readability of the dumped data, reduces data parsing time during the subsequent recovery phase, and provides a foundation for verifying the integrity of allocated physical pages, ensuring the accuracy of the recovered data.

[0055] Step a5: Write the description information, metadata array, and cyclic redundancy check mapping table array to the dump file.

[0056] Specifically, data writing follows the basic principles of file I / O (Input / Output) operations, writing various types of data to the corresponding areas of the dump file in a preset order.

[0057] This invention, through constructing a standardized dump file carrier, completing the filling of core fields in the file header and binding of integrity verification values, realizing the structured array transformation of raw memory data and the orderly writing of various core data, effectively improves the legality and version identifiability of dump files, endows dump data with complete integrity verification attributes, optimizes the organization efficiency of memory data and the convenience of subsequent parsing, provides a structured, traceable, and highly reliable persistent data source for the power outage recovery phase, and lays a solid foundation for the accurate reconstruction of the memory manager state.

[0058] In one specific embodiment, the memory manager is a buddy memory manager, and the free list is a free memory block storage list built by the buddy memory manager based on memory block size hierarchy.

[0059] Specifically, the buddy memory manager refers to a memory allocation management mechanism based on the buddy system. It divides the memory space into several memory blocks of size that are powers of 2, and realizes memory allocation and release through the division and merging of memory blocks. The construction of the free list is based on the hierarchical management logic of the buddy memory manager. It is hierarchically divided according to the size of the memory blocks, and each level corresponds to a free list. The free memory blocks stored in the list are of the same size and satisfy the buddy system, that is, two adjacent free memory blocks of the same size can be merged into a larger free memory block.

[0060] Based on the hierarchical management characteristics of the buddy memory manager, the free list can classify, store, and efficiently retrieve free memory blocks, supporting rapid memory allocation and release operations. Simultaneously, it provides structured free memory block information for the subsequent generation of the metadata array, ensuring that the metadata array accurately maps the distribution of free memory resources and provides a direct basis for the reconstruction of the free list during the power outage recovery phase. This achieves orderly management of free memory blocks, improves the execution efficiency of memory allocation and release, and reduces memory fragmentation. Furthermore, it provides a standardized and structured representation of free memory block information, ensuring that the metadata array accurately records the free memory state before the power outage, laying the foundation for accurate reconstruction of the free list during the recovery phase and ensuring the normal operation of the memory manager's memory allocation and release functions after recovery.

[0061] This invention employs a buddy memory manager and a free list constructed based on memory block size hierarchy to achieve efficient management and accurate representation of free memory resources. This provides stronger structural support for persistent storage and power-off recovery of memory data, and improves the efficiency and accuracy of power-off recovery of the memory manager.

[0062] This embodiment provides a detailed description of the process for obtaining the persistent trigger signal in the above embodiments. The specific implementation of this process includes the following steps:

[0063] Step b1: Obtain the thread wake-up time interval parameter.

[0064] Specifically, the thread wake-up interval parameter is a time threshold parameter used to control the periodic wake-up cycle of threads. It is read from a preset configuration storage location to ensure the accuracy and completeness of the parameter acquisition. It provides core time base data for the subsequent configuration of thread periodic wake-up rules and clarifies the standard for the thread wake-up interval.

[0065] Step b2: Verify the format and valid range of the time interval parameter using preset parameter verification rules to obtain the parameter verification result.

[0066] Specifically, the preset parameter validation rules are a predefined set of criteria for determining parameter validity. The time interval parameters are evaluated from two dimensions: parameter format compliance and valid numerical range. Format validation checks the data type and expression of the parameter, while range validation checks the numerical range of the parameter. The validation results are output through this dual-judgment process. Invalid parameters with incorrect formats or values ​​outside the valid range are filtered out to prevent them from entering the subsequent rule configuration process, ensuring the validity of the rule configuration. This completes the validity screening of the time interval parameters, ensuring that parameters entering the configuration process meet operational requirements and reducing the probability of anomalies during subsequent wake-up rule execution.

[0067] Step b3: If the parameter verification result is successful, configure the periodic wake-up rules for the thread based on the time interval parameter.

[0068] Specifically, the periodic wake-up rule is a running principle that controls threads to be woken up and executed at fixed time intervals. Based on the thread scheduling mechanism and the obtained time interval parameters, the wake-up period and execution timing of the threads are set, enabling the threads to be repeatedly woken up according to the preset time interval. By establishing a standardized periodic thread wake-up mechanism, the wake-up pattern of the threads is clarified, providing an execution basis for the orderly wake-up of threads.

[0069] Step b4: If the parameter verification result fails, configure the periodic wake-up rule of the thread according to the preset temporary time interval parameter.

[0070] Specifically, the preset temporary time interval parameter is a pre-stored backup time parameter. When the parameter verification fails and the normal parameter cannot be used, the backup parameter is enabled to ensure that the wake-up rule configuration process is not interrupted, maintain the basic operation of the thread wake-up mechanism, avoid the termination of the wake-up rule configuration process due to parameter verification failure, ensure the fault tolerance and continuity of the wake-up mechanism, prevent the interruption of trigger signal output, and maintain the stability of persistent trigger signal output.

[0071] Step b5: Wake up the thread according to the periodic wake-up rule and output a persistent trigger signal.

[0072] Specifically, according to the configured periodic wake-up rules, the target thread is activated when the preset time node is reached. After the thread is woken up, the internal signal output logic is triggered to generate and output a persistent trigger signal, which connects to the subsequent memory data persistence process and starts the output process of the persistent trigger signal. The thread wake-up action is transformed into the start instruction of the persistence process, realizing the effective connection between the wake-up mechanism and the persistence process, and realizing the stable and periodic output of the persistent trigger signal.

[0073] This invention, through the process of parameter acquisition, validity verification, fault tolerance configuration to signal output, achieves accurate, stable and continuous output of persistent trigger signals, providing a reliable start trigger mechanism for the memory data persistence process and improving the overall stability and fault tolerance of the memory manager power failure recovery scheme.

[0074] In one specific embodiment, step b5 above includes:

[0075] Step b51: After the thread is awakened, it queries the global mutex lock status of the memory manager.

[0076] Specifically, the global mutex state refers to the running status of the memory manager's global mutex, indicating whether it is currently held by another thread. Based on the mutex state monitoring mechanism, threads can read the real-time running flag of the global mutex through the system-provided mutex state query interface to obtain its holding status information. Pre-determining the availability of the global mutex provides a basis for subsequent mutex acquisition operations, preventing threads from blindly attempting to acquire the lock when it is already held, reducing unnecessary resource consumption, and mitigating thread blocking or resource contention caused by blindly acquiring the lock.

[0077] Step b52: If the mutex is not occupied, acquire the mutex directly.

[0078] Specifically, when the mutex is in an unoccupied state, the thread directly preempts the lock resource by calling the mutex acquisition interface, establishes its exclusive access to the core resources of the memory manager, and ensures that subsequent persistence-related operations can be executed in an environment without concurrency interference, thus guaranteeing the atomicity and security of the operations.

[0079] Step b53: If the mutex lock is already occupied, enter the preset waiting queue and start timing.

[0080] Specifically, the preset waiting queue is a predefined ordered queue structure used to store threads waiting to acquire a global mutex lock. When a thread cannot acquire the lock immediately, it actively enters the waiting queue, and a timing module is started to record the waiting time, providing a time benchmark for subsequent timeout judgment. This avoids threads frequently attempting to acquire the lock due to lock occupancy, reducing the unnecessary consumption of system resources; the waiting queue implements ordered queuing of threads, and the timing controls the waiting boundary, ensuring the reasonable allocation of system resources; it orderly manages threads waiting to acquire the lock, reducing the chaos of multi-threaded lock contention, and the timing provides support for subsequent timeout handling, preventing threads from waiting indefinitely.

[0081] Step b54: If the mutex lock is not acquired after the waiting time reaches the preset threshold, generate a lock contention log and exit the current persistence triggering process.

[0082] Specifically, the preset threshold is the maximum allowed time for a thread to wait to acquire a mutex lock. Its principle is based on a timeout fault tolerance mechanism. When the waiting time exceeds the preset threshold, it is determined that the current lock contention state cannot be alleviated in the short term, triggering an exception handling process, generating a log, and terminating the current triggering process. This prevents threads from occupying system resources due to prolonged waiting for lock resources, avoiding interference with other system processes. By generating lock contention logs, it provides data support for operations and maintenance personnel to trace lock contention anomalies.

[0083] Step b55: After acquiring the mutex lock, check whether the memory manager is currently in a memory operation idle state.

[0084] Specifically, the memory operation idle state is the running state in which the memory manager is not currently performing core memory operations such as memory allocation, release, and migration. By reading the running state flag of the memory manager, it is determined whether it is in a stable state in which persistent operations can be performed. This ensures that persistent triggering operations are only executed under the premise that the memory manager is running stably, avoiding conflicts between persistent operations and other core memory operations, and ensuring the integrity and consistency of memory data.

[0085] Step b56: If in operation, release the mutex and delay the next thread wake-up time.

[0086] Specifically, when the memory manager is detected to be busy, the acquired mutex lock resource is actively released. At the same time, the periodic wake-up parameters of the thread are adjusted to delay the next wake-up time, so as to reserve enough time for the memory manager to complete its operations. This avoids the core operations of the memory manager being unable to be executed due to the mutex lock being occupied. By delaying the wake-up, the probability of conflict between subsequent triggering processes and memory operations is reduced.

[0087] Step b57: If in an idle state, output a persistent trigger signal.

[0088] Specifically, when it is confirmed that the memory manager is in a stable and idle state, the thread executes the preset signal output logic, generates and sends a persistence trigger signal, starts the subsequent memory data acquisition and persistence process, ensures that the persistence process starts in a stable memory environment, and achieves matching and adaptation between the trigger signal and the memory state.

[0089] This invention achieves accurate and secure output of persistent trigger signals through processes such as lock state query, conditional lock acquisition, waiting timer fault tolerance, memory state verification, and conflict avoidance scheduling. It ensures the mutual exclusion of persistent operations and core memory management operations, improves process stability through fault tolerance mechanisms and scheduling optimization, effectively reduces concurrent conflicts and resource waste, and provides support for reliable execution of memory data persistence.

[0090] This embodiment provides a detailed description of the process in the above embodiment of filling the header core fields of the dump file based on the description information and the preset magic number version data. The specific implementation of this process includes the following steps:

[0091] Step c1: Obtain the supplementary information required for the core fields in the header of the dump file. The supplementary information includes the total number of pages, the number of virtual memory regions, the metadata offset, the metadata length, the cyclic redundancy check offset, and the cyclic redundancy check length.

[0092] Specifically, the core fields in the dump file header refer to the set of core fields located at the beginning of the dump file, used to store the file's basic identifiers and internal structural parameters. The acquisition of supplementary information is based on the data statistics and structure pre-parsing of the memory manager. By pre-analyzing and quantitatively analyzing the collected virtual memory region description information and the structured data array to be generated subsequently, various structural parameters and quantity information are extracted to provide comprehensive and complete structural data support for filling the core fields in the dump file header, ensuring that the header fields can fully characterize the internal structure and core attributes of the dump file.

[0093] Step c2: Initialize the header core fields and verification fields of the dump file based on the preset magic number version data and description information.

[0094] Specifically, the preset magic number version data refers to a composite fixed data that integrates the magic number and version data. The magic number is a predefined, unique, and fixed data sequence, while the version data is data that identifies the format of the dump file and the version of the recovery scheme. The core fields of the dump file header refer to the set of fields located at the beginning of the dump file that carry the basic identifier and core structural information of the file. The verification fields refer to the dedicated fields used for subsequent storage of data integrity verification results.

[0095] According to the preset mapping relationship between fields and data, the magic number in the preset magic number version data is filled into the corresponding legality identifier field in the file header, and the version data is filled into the compatibility identifier field. At the same time, the virtual memory area description information is filled into the corresponding functional position of the core field in the header. Finally, according to the initialization rules of the verification field, it is set to the initial state that meets the requirements of subsequent hash calculation. The structured filling logic is followed to ensure the standardization and accuracy of the initialization of all fields.

[0096] Step c3: Set the verification field to the preset initial state, and perform integrity calculation on the core fields of the header using the preset hash algorithm to obtain the unique field verification value.

[0097] Specifically, setting the verification field to a preset initial state is to avoid the verification field's own data interfering with the hash calculation result and to ensure the purity of the computing environment. Based on the preset hash algorithm, a one-way mathematical operation is performed on all valid data of the header core field to generate a hash value that can uniquely represent the integrity of the header core field data, i.e., the field verification value. This effectively eliminates the interference of the verification field on the integrity calculation. The hash algorithm generates a unique integrity verification identifier for the header core field, providing a reliable verification basis for subsequent header legality verification and significantly improving the anti-tampering capability of the dump file header.

[0098] Step c4: Fill the unique field validation value back into the validation field to obtain the complete file header.

[0099] Specifically, according to the structure definition and address mapping rules of the dump file header, the generated unique field verification value is accurately written to the corresponding storage location of the verification field, overwriting the original preset initial state value. The accurate address mapping logic of data writing ensures the accuracy of verification value backfilling. Finally, it is integrated to form a complete file header containing identifier, structure, and verification information, so that the dump file header has the dual ability of legality and integrity verification, which greatly improves the reliability and security of the dump file.

[0100] Step c5: Write the complete file header, aligned to a preset fixed byte length, to the beginning of the dump file.

[0101] Specifically, byte length alignment refers to adjusting the data storage location according to a preset fixed number of bytes to ensure that the data starting address is an integer multiple of the fixed number of bytes. This storage optimization involves aligning the complete file header according to a preset fixed byte length, following the file writing order mechanism, and writing the aligned complete file header to the starting storage area of ​​the dump file. This ensures that the file header is in a position that can be quickly retrieved and read, and that the file header can be quickly located, read, and parsed. At the same time, it ensures the standardization and compatibility of file header storage, adapting to the reading and parsing of different file systems.

[0102] This invention, through the collaborative efforts of supplementary information support, standardized initialization, integrity verification, and optimized storage, constructs a dump file header with complete identification, structure, and verification capabilities. This enhances the legality, tamper resistance, and parsability of the dump file, providing a reliable foundation for file verification and memory state reconstruction during the subsequent power outage recovery phase.

[0103] This embodiment provides a detailed description of the process in the above embodiment of generating a cyclic redundancy check mapping table array by performing structured processing on the starting virtual address and data content based on preset processing rules. The specific implementation of this process includes the following steps:

[0104] Step d1: Read the data content of the allocated physical page and the corresponding starting virtual address.

[0105] Specifically, obtaining complete allocated physical page data and associated starting virtual addresses lays a solid data foundation for the orderly conduct of subsequent processes and avoids abnormal generation of subsequent mapping table arrays due to missing data or incorrect address associations.

[0106] Step d2 involves performing a byte-by-byte checksum calculation on the data content of each allocated physical page using a preset cyclic redundancy check algorithm to obtain a unique checksum value.

[0107] Specifically, the standard polynomial and initial checksum of the CRC algorithm are first initialized. Then, the data content of each page is read byte by byte, and each byte of data is sequentially substituted into the preset CRC algorithm for iterative polynomial operations. Utilizing the determinism and unidirectionality of the algorithm, a checksum that uniquely represents the integrity and consistency of the page's data is generated. This generates a checksum with unique identification and error detection capabilities, accurately and uniquely representing the original integrity of each page's data. This provides reliable verification support for the accuracy of subsequent data recovery and significantly improves the anti-tampering and anti-damage capabilities of the allocated physical page data.

[0108] Step d3: Obtain the physical page frame number corresponding to each page in the allocated physical pages.

[0109] Specifically, the physical page frame number is a numerical identifier used to uniquely identify the storage location of a physical page in physical memory. Based on the page table mapping mechanism of the memory manager, the corresponding mapping relationship between virtual addresses and physical page frame numbers stored in the system page table is read. The corresponding physical page frame number is matched with the obtained starting virtual address, and the addressing and mapping logic of the page table is followed to ensure the accuracy and uniqueness of the obtained information.

[0110] Step d4: Bind the unique checksum, starting virtual address, and physical page frame number into a mapping entry according to a preset format.

[0111] Specifically, the mapping entry is a structured data unit used to store multiple types of related data information. It has a fixed data format, field definition and storage specifications. Based on the preset data format specifications, the unique check value, starting virtual address and physical page frame number are filled into the corresponding preset fields of the mapping entry, integrating the three discrete core information into a unified structured data unit, realizing the orderly association and standardized storage of data, and improving the data organization efficiency and readability.

[0112] Step d5 involves filtering out duplicate mapping entries and then summarizing them to generate a cyclic redundancy check mapping table array.

[0113] Specifically, the Cyclic Redundancy Check (CRC) mapping table array is a structured data array formed by orderly summarizing multiple standardized mapping entries according to preset rules. It is used to centrally store the associated verification information and address information of allocated physical pages. Based on the data deduplication algorithm in related technologies, all generated mapping entries are traversed. The uniqueness of the physical page frame number or the starting virtual address is used as the criterion to eliminate duplicate and invalid mapping entries. Then, according to the preset array organization rules, the valid mapping entries are orderly summarized and arranged to form a CRC mapping table array with a fixed structure and orderly arrangement.

[0114] Step d6: Add a length identifier field with a preset format to the Cyclic Redundancy Check Mapping Table Array.

[0115] Specifically, the length identifier field is a dedicated field used to store the overall length information and the number of entries in the data array. This allows the data reader to quickly obtain the overall data size and boundary information of the array. By statistically analyzing the actual number of valid mapped entries in the Cyclic Redundancy Check (CRC) map array, the quantity information is converted into length identifier data that meets storage requirements and filled into the array's preset start or end positions to form a complete length identifier field. This enables the CRC map array to have self-length identifier and boundary recognition capabilities. During subsequent power outage recovery, the reading and parsing process can quickly locate the array boundary and data size without additional traversal calculations, significantly improving the array's parsing efficiency and cross-system compatibility.

[0116] This invention, through a collaborative design of structured data integration, integrity verification, and standardized encapsulation, constructs a cyclic redundancy check mapping table array with complete information dimensions and error detection capabilities. This improves the traceability, integrity, and resolvability of allocated physical page data, providing reliable data support for the accurate reconstruction of allocated physical pages during the subsequent power outage recovery phase.

[0117] In one specific embodiment, step d2 above includes:

[0118] Step d21: Initialize the standard check polynomial and initial check value of the preset cyclic redundancy check algorithm.

[0119] Specifically, the standard check polynomial is a fixed mathematical polynomial used in the CRC algorithm to perform polynomial division operations. It is a core parameter that determines the detection capability and uniqueness of the check algorithm. The initial check value is a preset calculation baseline value before the CRC algorithm iterative calculation starts. Based on the preset configuration, the standard check polynomial is loaded into the calculation module, and the initial check value is assigned to the algorithm's calculation register. This completes the parameter configuration and environment initialization before the algorithm operation, eliminating the deviation in check value calculation caused by inconsistent parameter configuration or missing initial state, and providing a prerequisite guarantee for the accuracy and consistency of subsequent check value calculations.

[0120] Step d22: Read the physical page data byte by byte in ascending order of memory address, substitute the physical page data byte by byte into the verification algorithm for iterative calculation, and obtain the iterative result.

[0121] Specifically, the memory address incrementing order is a sequential reading order arranged from smallest to largest memory unit address; the iterative calculation is a continuous calculation method that uses the result of the previous calculation as the input value for the next calculation, repeatedly executing the same calculation logic. All bytes of data in the physical page are completely traversed according to the memory address incrementing order. For each byte read, it is combined with the current intermediate value in the arithmetic register, substituted into the initialized CRC algorithm to perform polynomial division, and the intermediate result in the arithmetic register is updated. After traversing all bytes, the final iterative intermediate result is obtained. Through continuous iterative calculation, the information of each byte of data is incorporated into the verification result, ensuring that the verification result can comprehensively represent the overall integrity of the physical page data.

[0122] Step d23: Invert the bits of the iteration result to obtain the final verification value.

[0123] Specifically, bitwise NOT processing refers to performing a logical NOT operation on each bit of binary data, converting "0" to "1" and "1" to "0". By converting the intermediate results obtained from iterative calculations into a standard binary data format and performing a logical NOT operation on each bit of that binary data, potential system computational biases during the CRC algorithm iteration process are eliminated. This generates a final check value with high uniqueness and strong anti-interference capabilities, further improving the accuracy of the check value in detecting data anomalies and ensuring that the subsequent recovery stage can accurately identify tampering, damage, or loss of physical page data.

[0124] Step d24: Bind and store the preset verification algorithm version information with the final verification value.

[0125] Specifically, the verification algorithm version information is a unique identifier used to identify the type, version, and parameter configuration of the CRC algorithm used. By integrating and encapsulating the preset verification algorithm version information and the final verification value according to a preset data format, a corresponding relationship is established between the two. This provides a precise algorithm configuration basis for verification value verification during the subsequent power outage recovery phase, ensuring that the verification process uses CRC algorithm parameters consistent with those used in the generation process.

[0126] This invention, through a collaborative design involving algorithm initialization, ordered iterative calculation, result optimization, and version association, generates a final verification value with high uniqueness and strong anti-interference capabilities. This improves the accuracy and reliability of data integrity verification for allocated physical pages, providing solid support for data validity verification during subsequent power outage recovery phases.

[0127] This embodiment provides a detailed description of the process of reconstructing the allocated physical pages of the memory manager in the above embodiments. The specific implementation of this process includes the following steps:

[0128] Step e1: Extract the file header and cyclic redundancy check mapping table array from the dump file based on the verification results.

[0129] Specifically, the file verification results during the power outage recovery phase are used as the criteria for data extraction. Data extraction is performed only on verified dump files. By parsing the storage layout information of the dump files, the file header at the beginning of the file is located. Furthermore, the storage area of ​​the Cyclic Redundancy Check (CRC) mapping table array is located using the preset CRC offset and length fields in the file header. Both types of data are then read and loaded into the memory buffer to complete the data extraction process. Using the verification results as a pre-screening condition for data extraction avoids invalid data extraction from illegal, damaged, or failed-verification dump files.

[0130] Step e2: Read the mapping entries in the Cyclic Redundancy Check (CRBC) mapping table array based on the CRBC offset and length information in the file header.

[0131] Specifically, the Cyclic Redundancy Check (CRC) offset refers to the address offset of the starting position of the CRC mapping table array in the dump file relative to the beginning of the file; the CRC length refers to the total number of bytes occupied by the mapping table array. Based on the offset and length information recorded in the file header, the storage range of the CRC mapping table array in the dump file is located, and all mapping entries within the storage range are read completely to ensure the integrity and accuracy of the read data, effectively avoiding data loss or redundancy caused by reading range deviations.

[0132] Step e3: Parse the mapping entries to obtain the starting virtual address, page frame number, and corresponding check data of the corresponding allocated physical page.

[0133] Specifically, based on the pre-defined field division rules of the mapping entries, the data content of each mapping entry is split, and the key information required to reconstruct the allocated physical pages is extracted from the structured mapping entries, including the address information required for location and the verification data required for verification. This eliminates the interference of the structured encapsulation of the original mapping entry data on subsequent processes and improves the execution efficiency and accuracy of subsequent steps.

[0134] Step e4: Based on the starting virtual address and page frame number, locate the target storage area of ​​the physical page to be reconstructed in the memory manager.

[0135] Specifically, the target storage area is a designated memory region in the memory manager used to store the reconstructed allocated physical pages. The starting virtual address determines the mapping location of the physical page in the virtual address space, and the page frame number is used to locate the actual storage address of the physical page in physical memory. By utilizing the mapping relationship between virtual and physical addresses, the target storage region of the physical page to be reconstructed is precisely located, ensuring that the original data content can be written to the correct memory region and avoiding memory management chaos caused by storage location deviations.

[0136] Step e5: Read the original data content of the allocated physical pages from the dump file and write it to the target storage area to obtain the reconstructed physical pages.

[0137] Specifically, based on file input / output (I / O) and memory write mechanisms, according to the original data storage location of the allocated physical pages recorded in the dump file, the corresponding original data content is read through the file read interface, and the read original data content is completely written into the located target storage area to complete the reconstruction of the allocated physical pages, providing physical page data to be verified for subsequent data consistency verification.

[0138] In one specific implementation, it also includes:

[0139] Step e6: Compare the data of the reconstructed physical page with the verification data in the cyclic redundancy check mapping table array to obtain a consistency result.

[0140] Specifically, the consistency result is the determination of whether the reconstructed physical page data matches the original check data. The current check value is calculated by applying the same Cyclic Redundancy Check (CRC) algorithm used to generate the original check data to the reconstructed physical page data. This current check value is then compared with the original check data in the CRC mapping table array. If they match, it is considered a match; otherwise, it is considered a mismatch. This process determines whether the reconstructed data has been tampered with, damaged, or lost, providing a basis for subsequent physical page classification.

[0141] Step e7: Based on the consistency results, filter and reconstruct physical pages to obtain consistent physical pages and inconsistent physical pages.

[0142] Specifically, based on the consistency result, physical pages with matching consistency results are defined as consistent physical pages, and physical pages with non-matching consistency results are defined as inconsistent physical pages. The processing direction for physical pages in different states is clarified, and validly reconstructed consistent physical pages are confirmed. Inconsistent physical pages with anomalies are then processed in a targeted manner to prevent invalid data from entering the normal memory scheduling process.

[0143] Step e8 marks the consistent physical pages as refactored.

[0144] Specifically, through the memory manager's preset status flag interface, a status flag indicating that the reconstruction of a physical page has been completed is added to the consistent physical page. This flag indicates that the physical page has been effectively reconstructed and can participate in memory allocation, release, and other operations normally.

[0145] Step e9: Obtain the page frame number, starting virtual address, and memory region identifier information of the inconsistent physical page, and organize them into inconsistent page records according to the preset log format.

[0146] Specifically, memory region identification information refers to the unique identifier used to distinguish the memory region to which an inconsistent physical page belongs; the preset log format refers to the predefined format specification used to standardize log content, field order, and storage format. By collecting key identification information of inconsistent physical pages, the information is structured and encapsulated according to the preset log format to generate inconsistent page records containing complete exception information, providing complete and standardized data for subsequent exception handling, problem tracing, and operational analysis.

[0147] Step e10: Send the inconsistent page record to the upper-layer application through the preset asynchronous notification interface, and receive the processing instructions from the upper-layer application.

[0148] Specifically, the preset asynchronous notification interface is used to implement non-blocking information exchange between the lower-level memory management module and the upper-level application; the processing instructions are the processing strategy instructions defined by the upper-level application for inconsistent physical pages. By pushing inconsistent page records to the upper-level application through the preset asynchronous notification interface, while maintaining a non-blocking communication channel, the system waits for and receives targeted processing instructions from the upper-level application. This enables collaborative interaction between the upper and lower-level modules, avoids blocking of the refactoring process due to waiting for processing instructions, ensures that exception handling accurately matches the upper-level business needs, and improves the system's collaboration and flexibility.

[0149] In step e11, if the processing instruction is to clear immediately, the data content of the inconsistent physical page is cleared and marked as unavailable.

[0150] Specifically, when an immediate zeroing instruction is received, the entire data content of the inconsistent physical page is zeroed through the data write interface of the memory manager. At the same time, an unavailable status mark is added to the physical page to prevent it from being included in the normal memory resource scheduling scope. This eliminates the interference of abnormal data in the inconsistent physical page, isolates the abnormal physical page through status marking, prevents abnormal data from being misread or used by the application, ensures system operation security, and improves the system's fault tolerance.

[0151] In step e12, if the processing instruction is delayed processing, the inconsistent page record is written to the preset log storage module.

[0152] Specifically, the preset log storage module is a pre-configured dedicated storage module for persistently storing system log information. When a delayed processing instruction is received, inconsistent page records are written to the preset log storage module according to the log storage specifications, thereby achieving long-term preservation of abnormal information and providing data retention for subsequent delayed processing or traceability analysis.

[0153] In one specific implementation, it also includes:

[0154] Step e13: Monitor the execution status of processing instructions in real time, generate a processing status report and send it back to the upper layer application, and update the abnormal page statistics of the memory manager based on the processing status report.

[0155] Specifically, the processing status report is a structured report that records the execution progress, results, and exceptions of processing instructions; the exception page statistics are statistics in the memory manager used to record information such as the number of inconsistent physical pages and their processing status. By monitoring the execution process of processing instructions in real time, execution status information is collected to generate a processing status report and send it back to the upper-layer application. At the same time, the processing results are synchronously updated to the exception page statistics in the memory manager to ensure the consistency of data between the upper and lower layers.

[0156] Step e14: After traversing all physical pages to be reconstructed, count the number of physical pages that have been reconstructed and generate a reconstruction completion report.

[0157] Specifically, the reconstruction completion report is a structured report summarizing the overall reconstruction status of allocated physical pages. After traversing all physical pages to be reconstructed, it counts the number of consistent physical pages that have been reconstructed, the number of abnormal physical pages that have not been reconstructed, and their handling status, among other core information. This information is then integrated according to a preset report format to generate the reconstruction completion report, achieving a systematic presentation of the reconstruction results. This provides accurate data for operational decisions and system optimization, marking the complete closure of the overall reconstruction process.

[0158] This invention, through a collaborative design involving verification, anomaly classification, and upper / lower-layer interaction, achieves precise reconstruction of allocated physical pages and controllable processing of abnormal data, improving the reliability and security of reconstruction results while ensuring the transparency and traceability of the reconstruction process. This provides core support for the overall reliability of the memory manager's power-off recovery.

[0159] This embodiment provides a detailed description of the process after writing the description information, metadata array, and cyclic redundancy check mapping table array into the dump file as described in the above embodiments. The specific implementation of this process also includes the following steps:

[0160] Step m1: The dump file is invoked through the preset file synchronization system to perform a synchronization operation.

[0161] Specifically, the default file synchronization system call is a system interface provided by the operating system used to force cached file data to be written to storage media (such as hard drives and flash memory). By calling this system interface, the delayed refresh logic of the system cache can be bypassed, and the cached data of the dump file can be directly synchronized to the physical storage medium, achieving true data persistence (i.e., forced disk write). This ensures that the data written to the dump file is truly written from the system cache to the physical storage medium, avoiding the loss of cached data due to power failure and ensuring the reliability of data persistence. It solves the problem of system cache data not being able to be written to disk in a timely manner, ensuring that the three types of core data are stored completely and stably in the physical medium, providing real and usable persistent data support for power failure recovery.

[0162] Step m2: Monitor the return status of the preset file synchronization system call to obtain the disk status result.

[0163] Specifically, the preset file synchronization system call will return a specific status indicator (success or failure) after execution. By monitoring this returned status indicator and combining it with preset status judgment rules, the execution result of the forced data write-to-disk operation can be accurately determined, and the write-to-disk status result can be obtained. This avoids blind process execution due to the inability to perceive the write-to-disk status, provides a prerequisite for subsequent fault-tolerant processing, and ensures the controllability of the persistence process.

[0164] Step m3: If the disk write status is successful, confirm that the data write is complete.

[0165] Specifically, when the disk persistence status is determined to be successful, it confirms that the data has been completely written to the physical storage medium, triggering the preset completion confirmation mechanism, marking the formal completion of the disk persistence phase of this round of data persistence, avoiding unnecessary process redundancy, and improving the execution efficiency of the overall persistence process.

[0166] Step m4: If the disk transfer result is a failure, after a preset delay, the system will call the preset file synchronization function to perform the synchronization operation on the dump file.

[0167] Specifically, when disk write failure occurs, the issue is assessed as potentially due to recoverable problems such as momentary system resource consumption or temporary abnormal response of the storage medium. A preset delay is used to provide a buffer period for recovery from the abnormal state. Subsequently, a preset file synchronization system call is invoked again to force a disk write operation, attempting to repair the disk write failure. This retry mechanism improves the success rate of data write to disk, avoids persistence failures caused by momentary anomalies, ensures the fault tolerance and continuity of the data persistence process, effectively reduces the impact of momentary anomalies on the persistence process, significantly increases the success probability of data write to disk, reduces data loss due to single disk write failures, and enhances the reliability of the persistence process.

[0168] In step m5, if the disk write status still fails when the number of retries reaches the preset limit, an alarm signal is triggered and a disk write failure log is generated.

[0169] Specifically, the preset upper limit is the maximum allowed number of retries for disk write-to-database. When the number of retries reaches the preset upper limit and still fails, it is determined to be an unrecoverable disk write-to-database anomaly. At this time, the preset alarm signal output logic is triggered, and key information such as the time, cause, and number of retries of the disk write-to-database failure are recorded in a preset log format to generate a disk write-to-database failure log. This system promptly reports serious disk write-to-database anomalies to the system operation and maintenance module or upper-layer applications, while retaining anomaly information to provide complete data for subsequent troubleshooting and operation and maintenance optimization. This prevents anomalies from being overlooked, facilitates quick location and handling of problems by operation and maintenance personnel, reduces the problem of data loss during power outage recovery due to long-term disk write-to-database failures, and improves the system's anomaly management capabilities.

[0170] Step m6: After the disk transfer is completed, set the dump file to the preset read-only attribute.

[0171] Specifically, the read-only attribute restricts the file permission to be read only and not modified or deleted. By calling the operating system's file permission setting interface, the permissions of the dump file are configured to the preset read-only mode, prohibiting any write, modification or deletion operations. This protects the persisted dump file from accidental operation or tampering, ensuring the integrity and security of the core data in the dump file, and providing permission-level protection for the data reliability during the subsequent power outage recovery phase.

[0172] This invention achieves reliable and persistent storage of core data through a collaborative design of ordered data writing, forced disk write protection, fault tolerance and retry, anomaly control and access control, and improves the integrity, security and traceability of dump files, providing a stable and reliable data foundation for the subsequent power outage recovery phase.

[0173] This embodiment provides a detailed description of the process of reconstructing the free list of the memory manager in the above embodiments. The specific implementation of this process includes the following steps:

[0174] Step n1: Extract the file header and metadata array from the dump file based on the verification results.

[0175] Specifically, based on the preset structured storage layout of the dump file, the verification result of the dump file is used as the basis for data extraction. Data extraction is only performed on the dump files that have passed the verification. The file header data located at the beginning of the dump file is located and read. By parsing the preset metadata offset field and metadata length field in the file header, the storage location and data range of the metadata array in the dump file are determined. Then, the file header data and metadata array data are loaded into the memory buffer according to the preset data reading rules.

[0176] Step n2: Read the metadata array into the memory buffer based on the metadata offset field and metadata length field in the file header.

[0177] Specifically, the metadata offset field records the offset of the starting position of the metadata array in the dump file header relative to the starting address of the file; the metadata length field records the total number of bytes occupied by the metadata array; and the memory buffer is a memory area used for temporary storage of read data. Based on the metadata offset field, the starting storage position of the metadata array in the dump file is located. Combined with the metadata length field, the read range is determined. Following the file input / output logic, the metadata array is completely read into the memory buffer, achieving a temporary migration of data from the storage medium to memory. This ensures the complete reading of the metadata array into the memory buffer and avoids data loss or redundancy due to read range deviations.

[0178] Step n3: Perform cyclic redundancy check on the metadata array in the memory buffer to obtain the array integrity result.

[0179] Specifically, the array integrity result determines whether the metadata array is complete and has not been tampered with. Integrity calculations are performed on the metadata array in the memory buffer, and the resulting checksum is compared with a preset original checksum. If they match, the array is considered complete; otherwise, it is considered incomplete. This verifies the integrity and authenticity of the metadata array, filters out tampered or damaged invalid metadata, avoids performing reconstruction operations based on erroneous data, and ensures the reliability of the reconstruction process.

[0180] Step n4: If the array integrity result is successful, parse the entries in the metadata array to obtain the starting physical page frame number and memory level information.

[0181] Specifically, a metadata array entry is a structured data unit storing information about free memory blocks within the metadata array; the starting physical page frame number is a value that uniquely identifies the storage location of a physical page in physical memory; and the memory level information represents the size hierarchy of free memory blocks. Following the preset field division rules for metadata array entries, the data content of each entry is split, and the starting physical page frame number and memory level information corresponding to the free memory block are extracted. This adherence to the mapping relationship between fields and data ensures the accuracy of the parsing results. By extracting the core address and hierarchy information required for reconstruction from the structured metadata, the encapsulated metadata is transformed into key parameters that can be directly used for memory block location and organization. This eliminates the interference of the structured encapsulation of the metadata array on subsequent processes and provides a direct basis for memory block status marking and linked list insertion.

[0182] Step n5: Based on the starting physical page frame number and memory level information, locate the memory block corresponding to the core release function of the memory manager, mark the memory block as free and record the marking timestamp.

[0183] Specifically, the core release function is the interface in the memory manager used to set the state of a memory block to free; the timestamp refers to the time information when the memory block is marked as free. The physical storage location of the target memory block is located by the starting physical page frame number, and the memory block's specifications are confirmed by combining the memory level information. The core release function is then called to trigger the memory block state modification logic, marking it as free. Simultaneously, a timestamp is generated according to the system time and associated with the storage, clearly defining the free attribute of the target memory block. This completes the precise marking of the memory block from an unknown state to a free state. The timestamp provides a traceable basis for memory block state changes, laying the state foundation for subsequent linked list insertions.

[0184] Step n6: Insert the memory blocks marked as free into the free linked list corresponding to the memory level, in ascending order of the memory level in the memory level information.

[0185] Specifically, memory tiers are hierarchical levels divided according to memory block size; the free list is a linked list structure used to store free memory blocks of the same memory tier. Free memory blocks are sorted from smallest to largest memory tier, and then, based on the correspondence between memory tiers and the free list, the sorted free memory blocks are sequentially inserted into the corresponding level's free list, generating a well-structured and clearly hierarchical free list. This achieves ordered management of free memory blocks, ensuring that matching free memory blocks can be quickly retrieved during subsequent memory allocation, thus improving memory management efficiency.

[0186] Step n7: After insertion, verify the integrity of the node pointers in the free list to obtain the list verification result.

[0187] Specifically, node pointer integrity refers to whether the predecessor and successor pointers of each node in the free linked list point correctly and are unbroken; the linked list verification result is the result of determining whether the free linked list structure is complete and valid. By checking the pointing logic of each node pointer, the association between nodes is verified to ensure that it conforms to the linked list structure specification. If there are no pointer errors or breaks, the verification is considered successful; otherwise, it is considered a failure. This confirms the structural integrity of the free linked list, promptly detects and troubleshoots potential pointer errors, node detachment, and other problems that may occur during linked list insertion, and avoids incomplete linked list structures affecting subsequent memory management operations.

[0188] In one specific implementation, it also includes:

[0189] Step n8: If the array integrity result is unsuccessful, or the linked list verification result is abnormal, terminate the reconstruction of the current free linked list.

[0190] Specifically, free list reconstruction relies on the integrity and accuracy of the metadata array. Damaged metadata leads to errors in the parsed physical page frame number and memory level information, resulting in a structurally abnormal free list. Loading an abnormal list can cause memory allocation conflicts, out-of-bounds access, and other problems. Terminating the process can block the propagation of erroneous data, preventing corrupted data from entering the runtime environment and reducing problems caused by metadata corruption.

[0191] Step n9: Clear the current memory buffer data and release temporary resources.

[0192] Specifically, failure to release temporarily allocated memory resources in a timely manner can cause memory leaks, affecting available memory space; furthermore, residual corrupted metadata may be misread by subsequent processes, triggering secondary exceptions. Clearing buffers and releasing resources can completely isolate erroneous data and eliminate the impact of residual erroneous data.

[0193] The embodiments of the present invention ensure the structural integrity and functional adaptability of the reconstructed free list through a collaborative design of precise metadata reading, integrity verification, structured parsing, hierarchical organization and structural verification, providing core structural support for the efficient operation of the memory manager after power failure recovery.

[0194] In one specific implementation, the following steps are also included:

[0195] Step f1: Obtain the execution completion status corresponding to multiple preset process nodes.

[0196] Specifically, during the power outage recovery process, the execution completion flag of each process node is read. The flag is set to an incomplete state when the node execution starts and automatically set to a completed state after the node execution ends. By obtaining the execution status of the process nodes, reliable input is provided for anomaly detection, ensuring the accuracy and timeliness of anomaly judgment.

[0197] Step f2: Based on the execution completion status, generate a status identifier corresponding to the process node.

[0198] Specifically, the read scattered execution completion status is converted into a binary status identifier according to a preset encoding rule. Different binary bits correspond to the execution status of different process nodes. For example, 0 indicates incomplete and 1 indicates completed, generating a unified identifier containing the status information of all nodes.

[0199] Binary encoding can represent multiple discrete state information with minimal storage space, facilitating rapid processing and transmission. Unified encoding rules ensure the compatibility and recognizability of state identifiers across different modules of the system, transforming scattered, unstructured execution completion states into structured state identifiers in a unified format, simplifying subsequent exception judgment logic, reducing system processing complexity, and minimizing system resource consumption.

[0200] Step f3: Determine the execution status of the process node based on the status identifier.

[0201] Specifically, the generated status identifier is compared bit by bit with the preset normal status. If any bit in the status identifier does not match the corresponding bit in the normal status template, the process node is determined to have abnormal execution. The preset normal status template defines the state combination of the process node under normal execution conditions. By judging the execution status of the process node, process nodes with execution abnormalities are identified.

[0202] Step f4: If the execution status is abnormal execution, terminate the associated execution thread corresponding to the process node.

[0203] Specifically, when an abnormal execution process node exists, the thread state is immediately set to terminated, stopping the continued execution of the abnormal process, cutting off the execution link of the abnormal process, blocking the propagation path of erroneous data and abnormal states, and protecting the normal operation of other parts.

[0204] This invention, by constructing multi-node anomaly detection and termination settings in the power-off recovery process, can promptly terminate associated execution threads when an anomaly is detected, effectively blocking error propagation paths and improving the reliability and stability of the memory manager's power-off recovery process.

[0205] In one specific implementation, the following steps are also included:

[0206] Step k1: Obtain process execution data after the associated execution thread terminates.

[0207] Specifically, the process execution data records the running status and context information when the anomaly occurs, providing complete context data support for resource cleanup, system recovery and log generation after the anomaly is terminated, ensuring that subsequent operations can be performed based on accurate anomaly situation information.

[0208] Step k2: Clean up the temporary resources corresponding to the associated execution threads based on the process running data, destroy incomplete memory mapping relationships and reset the status flag of the memory manager.

[0209] Specifically, based on the list of allocated resources in the process execution data, it iterates through and releases temporary memory blocks, file handles, and kernel objects allocated by the associated execution thread; it iterates through the memory management page table and destroys any incomplete virtual address to physical address mappings; and it modifies the global state variables of the memory manager to an uninitialized state.

[0210] Execution threads that terminate abnormally will leave behind unreleased system resources and incomplete memory mappings. These residual resources can easily lead to memory leaks and address space conflicts; incorrect memory manager status flags can cause subsequent processes to malfunction. Cleaning up residual resources and resetting the state can eliminate all residual effects caused by the exception.

[0211] Step k3: Invoke the preset cold start process based on the status flag.

[0212] Specifically, the system reads the global status flag of the memory manager. When an abnormal termination status is detected, a cold start notification signal is sent to trigger the initialization process of the full node. The cold start process can completely rebuild the runtime environment, ensuring availability when the existing memory environment cannot be repaired.

[0213] Step k4: Reconstruct the memory manager's runtime environment based on the preset cold start process.

[0214] Specifically, it performs physical memory resource detection and partitioning operations, establishes a physical memory page frame management structure, constructs a virtual memory address space, initializes page tables and address translation mechanisms, initializes memory allocation and release algorithms, establishes memory pools and caching mechanisms, and completes the initialization of memory access permission control mechanisms.

[0215] The cold start process completely clears all states and data of the original memory operating environment, builds a brand new memory management structure, completely eliminates the impact of all abnormal states, and ensures that the rebuilt operating environment is normal.

[0216] Step k5: Generate a structured exception log based on the process execution data and store the structured exception log.

[0217] Specifically, data such as the time of occurrence of the exception, the number of the exception node, the error code, the program counter value, and the stack backtrace information are extracted from the process operation data and organized into exception log entries according to a preset structured format; the generated exception log entries are written to a fixed log partition of non-volatile memory.

[0218] Structured logs can organize scattered anomaly information into a format that is easy for computers to process and for humans to analyze; non-volatile memory can ensure that log data is not lost after system power failure and restart, providing a permanent record for subsequent troubleshooting.

[0219] This invention eliminates all residual effects of the anomaly by performing a complete resource cleanup, environment reset, cold start fallback, and anomaly log recording process after the abnormal execution thread terminates, quickly restoring the system to normal operation. It also provides complete data support for subsequent troubleshooting and system optimization, effectively improving the reliability and maintainability of the memory manager's power-off recovery process.

[0220] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0221] Figure 3 This is a schematic diagram of the structure of the memory manager power-off recovery device provided in an embodiment of this application. Figure 3 As shown, embodiments of this application also provide a memory manager power-off recovery device 30.

[0222] The acquisition module 301 is used to acquire the persistence trigger signal and the global mutex lock of the memory manager. The persistence trigger signal is used to start the persistent storage of data information in the memory manager.

[0223] The acquisition module 301 is also used to acquire data information stored in the memory manager based on persistent trigger signals under the exclusive access control of the global mutex lock. The data information includes description information of the virtual memory region, the starting page frame number and memory level of the free block in the free list, and the starting virtual address and data content of the allocated physical page.

[0224] The creation module 302 is used to create a dump file based on the data information, and to process the start page frame number and memory level, start virtual address and data content of the free block according to the preset processing rules to obtain the processed data information, and write the processed data information and description information into the dump file;

[0225] The verification module 303 is used to read the file header of the dump file and verify the dump file based on preset verification rules and the file header when the memory manager is restored from a power failure, so as to obtain the verification result;

[0226] Recovery module 304 is used to reconstruct the virtual memory region, free list and allocated physical pages of the memory manager based on the verification results and dump file, so as to recover the data information of the memory manager.

[0227] For a description of the features in the embodiment corresponding to the memory manager power-off recovery device, please refer to the relevant description of the embodiment corresponding to the memory manager power-off recovery method, which will not be repeated here.

[0228] Figure 4 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 4 As shown, the electronic device 40 includes at least one processor 401 and a memory 402. Optionally, the electronic device 40 also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0229] In the specific implementation process, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above method.

[0230] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0231] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0232] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0233] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0234] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the memory manager power-off recovery method when it is run.

[0235] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0236] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the memory manager power-off recovery method.

[0237] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the memory manager power-off recovery method.

[0238] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0239] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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.

[0240] The above provides a detailed description of a memory manager power-off recovery method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for power failure recovery of a memory manager, the method comprising: include: Acquire the persistence trigger signal and the global mutex lock of the memory manager. The persistence trigger signal is used to initiate the persistent storage of data information in the memory manager. Under the exclusive access control of the global mutex lock, the data information stored in the memory manager is collected based on the persistent trigger signal. The data information includes the description information of the virtual memory region, the starting page frame number and memory level of the free block in the free list, and the starting virtual address and data content of the allocated physical page. A dump file is created based on the data information, and the starting page frame number, memory level, starting virtual address, and data content of the free block are processed according to preset processing rules to obtain processed data information. The processed data information and the description information are then written into the dump file. A dump file is created based on the data information, and the starting page frame number, memory level, starting virtual address, and data content of the free block are processed according to preset processing rules to obtain processed data information. The processed data information and the description information are then written into the dump file, including: Create the dump file, fill the header core field of the dump file according to the description information and the preset magic number version data, and set the verification field in the header core field to the preset initial state; The data content of the core header fields, excluding the verification fields, is analyzed by a preset hash algorithm to obtain the field verification values ​​and backfill them to form the file header, which is then written to the starting position of the dump file. The free block's starting page frame number and memory level are structured and processed according to preset processing rules to generate a metadata array; Based on preset processing rules, the starting virtual address and data content are structured to generate a cyclic redundancy check mapping table array; Write the description information, metadata array, and cyclic redundancy check mapping table array into the dump file; In the event of a power outage recovery of the memory manager, the file header of the dump file is read and the dump file is verified based on preset verification rules and the file header to obtain the verification result; Based on the verification results and the dump file, the virtual memory region, free list, and allocated physical pages of the memory manager are reconstructed to restore the data information of the memory manager.

2. The power fail recovery method for a memory manager according to claim 1, wherein, The acquisition of the persistent trigger signal includes: Get the time interval parameter for thread wake-up; The format and valid range of the time interval parameter are verified by using preset parameter verification rules to obtain the parameter verification result; If the parameter verification result is successful, configure the periodic wake-up rule for the thread based on the time interval parameter; If the parameter verification result fails, configure the periodic wake-up rule of the thread according to the preset temporary time interval parameter; The thread is woken up according to the periodic wake-up rule, and the persistent trigger signal is output.

3. The memory manager power-off recovery method according to claim 1, characterized in that, The header core fields of the dump file are filled according to the description information and the preset magic number version data, including: The supplementary information required to obtain the core fields of the dump file header includes the total number of pages, the number of virtual memory regions, metadata offset, metadata length, cyclic redundancy check offset, and cyclic redundancy check length. Initialize the header core fields and verification fields of the dump file based on the preset magic number version data and the description information; Set the verification field to a preset initial state, and perform integrity calculation on the core header field using a preset hash algorithm to obtain a unique field verification value; The unique field verification value is then filled back into the verification field to obtain the complete file header; The complete file header is aligned to a preset fixed byte length and written to the starting position of the dump file.

4. The memory manager power-off recovery method according to claim 1, characterized in that, Based on preset processing rules, the starting virtual address and data content are structured to generate a cyclic redundancy check mapping table array, including: Read the data content of the allocated physical page and its corresponding starting virtual address; A unique check value is obtained by calculating the data content corresponding to each page in the allocated physical page byte by byte using a preset cyclic redundancy check algorithm. Obtain the physical page frame number corresponding to each page in the allocated physical pages; The unique check value, the starting virtual address, and the physical page frame number are bound together in a preset format to generate a mapping entry; After filtering out duplicate mapping entries, the data are summarized to generate a cyclic redundancy check mapping table array. Add a length identifier field with a preset format to the cyclic redundancy check mapping table array.

5. The memory manager power-off recovery method according to claim 4, characterized in that, The data content corresponding to each page in the allocated physical pages is calculated byte by byte using a preset cyclic redundancy check algorithm, including: Initialize the standard check polynomial and initial check value of the preset cyclic redundancy check algorithm; The physical page data is read byte by byte in ascending order of memory address. The physical page data is then substituted byte by byte into the verification algorithm for iterative calculation to obtain the iterative result. The iteration results are inverted bitwise to obtain the final verification value; The preset verification algorithm version information is bound and stored with the final verification value.

6. The memory manager power-off recovery method according to claim 1, characterized in that, Reconstructing the allocated physical pages of the memory manager includes: Based on the verification results, extract the file header and cyclic redundancy check mapping table array from the dump file; Based on the cyclic redundancy check offset and length information in the file header, read the mapping entries in the cyclic redundancy check mapping table array; The mapping entries are parsed to obtain the starting virtual address, page frame number, and corresponding check data of the corresponding allocated physical page; Based on the starting virtual address and the page frame number, locate the target storage area of ​​the physical page to be reconstructed in the memory manager; The original data content of the allocated physical pages is read from the dump file and written to the target storage area to obtain the reconstructed physical pages.

7. The memory manager power-off recovery method according to claim 6, characterized in that, Also includes: The data of the reconstructed physical page is compared with the verification data in the cyclic redundancy check mapping table array to obtain a consistency result; Based on the consistency results, the reconstructed physical pages are filtered to obtain consistent physical pages and inconsistent physical pages; Mark the consistent physical page as refactoring complete; Obtain the page frame number, starting virtual address, and memory region identifier information of the inconsistent physical page, and organize them into an inconsistent page record according to a preset log format; The inconsistent page record is sent to the upper-layer application through a preset asynchronous notification interface, and the processing instructions fed back by the upper-layer application are received. If the processing instruction is to clear immediately, then the data content of the inconsistent physical page is cleared and marked as unavailable; If the processing instruction is a delayed processing, the inconsistent page record is written to the preset log storage module.

8. The memory manager power-off recovery method according to claim 7, characterized in that, Also includes: The execution status of the processing instructions is monitored in real time, a processing status report is generated and sent back to the upper-layer application, and the abnormal page statistics of the memory manager are updated based on the processing status report; After traversing all physical pages to be reconstructed, count the number of physical pages that have been reconstructed and generate a reconstruction completion report.

9. The memory manager power-off recovery method according to claim 1, characterized in that, After writing the description information, metadata array, and cyclic redundancy check mapping table array into the dump file, the process further includes: The dump file is invoked through a preset file synchronization system to perform a synchronization operation; Monitor the return status of the preset file synchronization system call to obtain the disk write status result; If the disk write status result is successful, it confirms that the description information, the metadata array, and the cyclic redundancy check mapping table array have been successfully written to disk. If the disk transfer status result is a failure, after a preset delay, the preset file synchronization system will be used to call the dump file to perform a synchronization operation. If the disk write status still fails when the number of retries reaches the preset limit, an alarm signal is triggered and a disk write failure log is generated. After the disk transfer is completed, the dump file is set to a preset read-only attribute.

10. The memory manager power-off recovery method according to claim 1, characterized in that, Reconstructing the free list of the memory manager includes: Based on the verification results, extract the file header and metadata array from the dump file; The metadata array is read into a memory buffer based on the metadata offset field and metadata length field in the file header; Cyclic redundancy check is performed on the metadata array in the memory buffer to obtain the array integrity result; If the array integrity result is passed, the entries in the metadata array are parsed to obtain the starting physical page frame number and memory level information; Based on the starting physical page frame number and memory level information, locate the memory block corresponding to the core release function of the memory manager, mark the memory block as free and record the marking timestamp; According to the memory level information, the memory blocks marked as free are inserted into the free linked list corresponding to the memory level in ascending order of memory level; After insertion, verify the integrity of the node pointers in the free linked list to obtain the linked list verification result.

11. The memory manager power-off recovery method according to claim 10, characterized in that, Also includes: If the array integrity result is unsuccessful, or the linked list verification result is abnormal, terminate the reconstruction of the current free linked list; Clear the current memory buffer data and release temporary resources.

12. The memory manager power-off recovery method according to claim 1, characterized in that, Also includes: Obtain the execution completion status corresponding to multiple preset process nodes; Based on the execution completion status, generate a status identifier corresponding to the process node; The execution status of the process node is determined based on the status identifier; If the execution status is abnormal, the associated execution thread corresponding to the process node is terminated.

13. The memory manager power-off recovery method according to claim 12, characterized in that, Also includes: Obtain the process execution data after the associated execution thread terminates; Based on the process execution data, the temporary resources corresponding to the associated execution thread are cleaned up, incomplete memory mapping relationships are destroyed, and the status flag of the memory manager is reset. The preset cold start process is invoked based on the status identifier; The memory manager's runtime environment is reconstructed based on the preset cold start process; A structured exception log is generated based on the process execution data, and the structured exception log is stored.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the memory manager power-off recovery method as described in any one of claims 1 to 13 when executing the computer program.

Images