Memory management methods, devices, electronic devices, storage media and products

Abstract

This application provides a memory management method, apparatus, electronic device, storage medium, and product, relating to the field of memory management. The method includes: obtaining a pre-boot process and generating a client based on the pre-boot process; sending execution information of a target program to be launched to the pre-boot process via the client; and managing the memory of the target program based on the execution information via the pre-boot process. This application addresses the technical problem in the prior art where, when a process occupies a large amount of memory at startup, the lack of timely memory usage control leads to operating system crashes.

Description

Technical Field

[0001] This application relates to the field of memory management, and more specifically, to a memory management method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] The amount of memory in mobile devices is generally fixed. Processes running within a mobile operating system request memory from the operating system to ensure their proper functioning. However, because the memory requested by a process is not released during execution, the memory usage of that process continuously increases, leading to memory leaks and, in severe cases, system crashes. Therefore, how to manage the memory usage of programs running within the operating system has become an urgent technical problem to be solved.

[0003] Most operating systems currently rely on Linux kernel-based CGroup (Control Groups) technology to manage process memory usage. By writing restrictions to specific locations in the kernel, the memory usage of corresponding processes is limited, thus achieving process control. However, some processes may already be consuming a large amount of memory at startup. CGroup technology requires knowing the process ID before configuring memory control, which may be too late and fail to achieve the desired memory management effect. In some cases, this can even lead to serious consequences such as operating system crashes. Summary of the Invention

[0004] This application provides a memory management method, apparatus, electronic device, storage medium, and product to solve the technical problem in the prior art where the operating system crashes due to the lack of timely management of memory usage when a process occupies a large amount of memory at startup.

[0005] According to one aspect of the embodiments of this application, a memory management method is provided, including:

[0006] Obtain the pre-start process and generate a client based on the pre-start process;

[0007] The client sends the execution information of the target program to be launched to the pre-launch process.

[0008] The pre-boot process performs memory management on the target program based on the execution information.

[0009] In one possible implementation, obtaining the pre-startup process includes:

[0010] Start the parent process that provides the pre-startup process template;

[0011] A pre-boot process is generated based on the parent process using kernel functions; wherein the pre-boot process is a child process of the parent process.

[0012] In one possible implementation, sending the execution information of the target program to be launched to the pre-launch process via the client includes:

[0013] The client obtains the execution information of the target program to be launched;

[0014] The client sends the execution information of the target program to the pre-start process; the execution information includes the process identification number, file path, and file name.

[0015] In one possible implementation, the memory management of the target program by the pre-boot process based on the execution information includes:

[0016] If it is determined that the target program needs to be controlled, the process ID of the target program and the preset memory size received by the pre-boot process are written to the corresponding locations in the operating system kernel.

[0017] In one possible implementation, the memory management of the target program by the pre-boot process based on the execution information includes:

[0018] The pre-boot process loads the target program's binary file into memory using the obtained file path;

[0019] After loading is complete, obtain the handle returned by the target program;

[0020] The target program is executed based on the handle.

[0021] In one possible implementation, executing the target program based on the handle includes:

[0022] The address of the target program's main function is obtained through the handle;

[0023] Locate and execute the main function of the target program based on its address;

[0024] The pre-startup process name is changed to the file name of the target program, and a process end flag is sent to the parent process.

[0025] According to another aspect of the embodiments of this application, a memory management apparatus is provided, comprising:

[0026] A startup module is used to obtain a pre-startup process and generate a client based on the pre-startup process;

[0027] The information acquisition module is used to send the execution information of the target program to be launched to the pre-launch process through the client;

[0028] The management module is used to manage the memory of the target program based on the execution information through the pre-startup process.

[0029] According to another aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described in the above embodiments.

[0030] According to another aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method described in the above embodiments.

[0031] According to another aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the above embodiments.

[0032] The beneficial effects of the technical solutions provided in this application are:

[0033] The memory management method provided in this application involves obtaining a pre-startup process and generating a client based on the pre-startup process. The client then sends the execution information of the target program to be started to the pre-startup process. The pre-startup process manages the memory of the target program based on the execution information. This solution effectively controls the memory usage of the target program by pre-starting a lightweight process and then running the main function of the target program through that lightweight process. This avoids situations where one or more programs request a large amount of memory at startup, but the CGroup technology fails to configure and control memory in a timely manner, resulting in memory management failure. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0035] Figure 1 A flowchart illustrating a memory management method provided in an embodiment of this application;

[0036] Figure 2 This is a detailed flowchart of step S101 of an embodiment of this application.

[0037] Figure 3 This is a detailed flowchart of step S102 in one embodiment of this application.

[0038] Figure 4This is a detailed flowchart of step S103 in one embodiment of this application.

[0039] Figure 5 This is a general flowchart of a memory management method provided in an embodiment of this application.

[0040] Figure 6 This is a schematic diagram of the structure of a memory management device provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] The embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions of the embodiments of this application.

[0043] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this application mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “and / or” as used herein indicates at least one of the items defined by the term; for example, “A and / or B” can be implemented as “A,” or as “B,” or as “A and B.”

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0045] Figure 1 This is a flowchart illustrating a memory management method provided in an embodiment of this application. The embodiment of this application provides a memory management method, which includes steps S101 to S103.

[0046] S101. Obtain the pre-start process and generate a client based on the pre-start process.

[0047] The pre-boot process is a lightweight process that typically does not participate in implementing the main functions of the operating system and usually only has socket communication capabilities. This pre-boot process serves two purposes: first, it obtains the process IDs (PIDs) of other processes, providing the necessary conditions for CGroup to implement process memory management; second, it creates a socket client to communicate with relevant modules of the operating system. These modules send the path and filename of the executable file corresponding to the process to be managed to the pre-boot process via the socket. The pre-boot process then calls the relevant kernel functions of the operating system to run the memory management program based on the executable file path. It is understood that the client in this step generally refers to a socket client.

[0048] For specific implementation details of CGroup, please refer to the existing technology; the embodiments in this application will not be repeated here.

[0049] S102. The client sends the execution information of the target program to be started to the pre-start process.

[0050] The target program includes all programs running in the operating system, and may include, but is not limited to, system programs of the operating system and externally installed applications. The execution information of the target program may include, but is not limited to, the process ID (PID) of the target program, the file path of the target program, and the file name of the target program.

[0051] S103. The pre-boot process performs memory management on the target program based on the execution information.

[0052] The memory management method provided in this application involves obtaining a pre-boot process and generating a client based on the pre-boot process; sending the execution information of the target program to be launched to the pre-boot process through the client; and managing the memory of the target program through the pre-boot process based on the execution information. This solution effectively manages the operating system's memory by pre-booting a lightweight process and then running the target program's main function through that lightweight process. This avoids situations where one or more programs request a large amount of memory at startup, but the CGroup technology fails to configure and manage this memory in a timely manner, leading to memory management failure.

[0053] Figure 2 This is a detailed flowchart of step S101 in one embodiment of this application. In some embodiments, obtaining the pre-startup process includes:

[0054] Start the parent process that provides the pre-startup process template;

[0055] A pre-boot process is generated based on the parent process using kernel functions; wherein the pre-boot process is a child process of the parent process.

[0056] In this embodiment, the parent process provides a template for the child process. The kernel function obtains the corresponding child process by cloning the parent process. This child process is the pre-boot process that participates in subsequent memory management. Since each pre-boot process is cloned from the parent process, when it is necessary to modify the relevant attributes of each pre-boot process, only a specific attribute of the parent process needs to be modified, which will modify all the subsequent pre-boot processes of that specific attribute. This adjustment and modification method makes memory management more convenient; and it does not require rewriting a pre-boot process for each memory management operation, but can be obtained by cloning from the parent process, making memory management more operable.

[0057] For example, the parent process is System-Booster, and the pre-boot process is Booster. The operating system starts the System-Booster process, which clones the child process Booster using the fork() function, thus completing the step of generating a pre-boot process based on the parent process through kernel functions.

[0058] Figure 3 This is a detailed flowchart of step S102 in one embodiment of this application. In some embodiments, sending the execution information of the target program to be launched to the pre-launch process through the client includes:

[0059] The client obtains the execution information of the target program to be launched;

[0060] The client sends the execution information of the target program to the pre-start process; the execution information includes the process identification number, file path, and file name.

[0061] In this embodiment, the process ID (PID) of the target program is obtained through a socket client created by the pre-boot process. Simultaneously, the operating system issues a command that enables the pre-boot process to obtain the file path and filename of the target program via the socket client, facilitating subsequent memory management. Because socket clients have a small footprint and high communication efficiency, using a socket client for communication within the pre-boot process achieves lightweight and convenient memory management.

[0062] For example, Booster creates a socket client and obtains the process ID (PID) of the target program. The relevant modules of the operating system then send the path and name of the executable file that needs to be managed to Booster through the socket client.

[0063] Figure 4This is a detailed flowchart of step S103 in one embodiment of this application. In some embodiments, the step of managing the memory of the target program based on the execution information through the pre-startup process includes:

[0064] If it is determined that the target program needs to be controlled, the process ID of the target program and the preset memory size received by the pre-boot process are written to the corresponding locations in the operating system kernel.

[0065] Optionally, the target program includes programs that require management and programs that do not require management. The pre-boot process first determines whether a target program needs management. This determination can be made based on pre-defined file types or flag values, or automatically by setting a file size threshold. Methods include, but are not limited to, these. Optionally, a flag value can be used to distinguish whether a target program needs management: a flag of 1 indicates a program requiring management, and a flag of 0 indicates a program not requiring management. Typically, the memory usage of the target program is managed using the process ID corresponding to that program.

[0066] In this embodiment, in order to continue the subsequent process of memory management for the target program, the received process ID and the maximum number of bytes of memory that the process can use are written to the corresponding locations in the operating system kernel. It is understood that the specific location written to the operating system kernel is related to the memory management technology used by the operating system kernel. For example, if the Linux system kernel manages memory using CGroup technology, Booster typically writes the process PID and the maximum number of bytes of memory that the process can use to ` / sys / fs / cgroup / memory / control / cgroup.procs` and ` / sys / fs / cgroup / memory / control / memory.limit_in_bytes`, respectively.

[0067] In some embodiments, the step of managing the memory of the target program through the pre-boot process based on the execution information includes:

[0068] The pre-boot process loads the target program's binary file into memory using the obtained file path;

[0069] After loading is complete, obtain the handle returned by the target program;

[0070] The target program is executed based on the handle.

[0071] In this embodiment, the pre-boot process locates and loads the binary file of the target program that requires memory management via a file path. By loading the binary file, it finally obtains the handle returned by the target program. A handle can be understood as an identifier used to identify an object or item, and this handle is used for subsequent memory management of the target program.

[0072] For example, the Linux system kernel function dlopen() is called to load the binary file of the target program received by Booster into memory and return a handle.

[0073] The prototype of the dlopen() function is: void*dlopen(const char*pathname,int mode).

[0074] In some embodiments, executing the target program based on the handle includes:

[0075] The address of the target program's main function is obtained through the handle;

[0076] Locate and execute the main function of the target program based on its address;

[0077] The pre-startup process name is changed to the file name of the target program, and a process end flag is sent to the parent process.

[0078] In this embodiment, the address of the main function of the target program can be obtained through the handle. By finding this address and executing the corresponding main function, the target program can be run while limiting its memory usage. After the target program finishes running, an end flag is sent to the parent process that provided the pre-boot process template, marking the end of memory control over the target program. The process name of the pre-boot process is changed to the filename of the target program to distinguish it from other similar pre-boot processes. Changing the name also facilitates subsequent debugging and troubleshooting of the pre-boot process.

[0079] It is understandable that the file path of the target program and the address of the main function of the target program are usually not the same. The file path is an identifier pointing to a file text; while the address of the main function is the address of the encoded program existing in the program code, which is the main function. In this application, the address of the main function mainly refers to the address of the main function entry point.

[0080] Optionally, after the parent process receives the process end signal, it continues to clone the parent process to generate a pre-start process and continue to manage the memory of the new target program.

[0081] For example, the main function is the main function. The Linux system kernel function dlsym() is called, and the address of the main function is obtained using the handle returned by dlsym().

[0082] The prototype of the dlsym() function is: void*dlsym(void*handle,constchar*symbol).

[0083] The Booster calls the Linux system function `prctl()` to modify the Booster process name to the received filename and sends a message to its parent process, System-Booster, indicating that it has obtained information about the target program to be run. It should be noted that at this point, System-Booster calls the Linux kernel function `fork()` to clone a new Booster process, preparing for the startup of the next target program.

[0084] Finally, based on the obtained address of the main function of the current target program, the main function is executed, and the current target program is run.

[0085] Figure 5 This is a general flowchart of a memory management method in a Linux system provided in this application embodiment. It should be noted that the process ID of the target program requiring memory management is known before setting up the CGroup. Then, the Linux kernel functions dlopen() and dlsym() are called sequentially to obtain the address of the target program's main function and execute it, causing it to run within the Booster. Therefore, this method of pre-starting the Booster process and then running the target program's main function can effectively manage its memory.

[0086] The memory management method provided in this application involves obtaining a pre-boot process and generating a client based on it; sending the execution information of the target program to be launched to the pre-boot process through the client; and then managing the memory of the target program based on the execution information through the pre-boot process. This solution effectively controls the memory usage of the target program by pre-booting a lightweight process and then running the main function of the target program through that lightweight process. This avoids situations where one or more programs request a large amount of memory at startup, but the CGroup technology fails to configure and control memory in a timely manner, leading to memory management failure.

[0087] See Figure 6 This is a schematic diagram of a memory management device 500 provided in an embodiment of this application. The memory management device 500 includes:

[0088] The startup module 501 is used to obtain the pre-startup process and generate a client based on the pre-startup process.

[0089] The acquisition of the pre-startup process includes:

[0090] Start the parent process that provides the pre-startup process template;

[0091] A pre-boot process is generated based on the parent process using kernel functions; wherein the pre-boot process is a child process of the parent process.

[0092] The information acquisition module 502 is used to send the execution information of the target program to be started to the pre-start process through the client;

[0093] The step of sending the execution information of the target program to be launched to the pre-launch process through the client includes:

[0094] The client obtains the execution information of the target program to be launched;

[0095] The client sends the execution information of the target program to the pre-start process; the execution information includes the process identification number, file path, and file name.

[0096] The management module 503 is used to manage the memory of the target program based on the execution information through the pre-startup process.

[0097] The step of managing the memory of the target program through the pre-boot process based on the execution information includes:

[0098] If it is determined that the target program needs to be controlled, the process ID of the target program and the preset memory size received by the pre-boot process are written to the corresponding locations in the operating system kernel.

[0099] The pre-boot process loads the binary file of the target program into memory using the obtained file path; after loading, it obtains the handle returned by the target program; and executes the target program based on the handle.

[0100] Obtain the address of the main function of the target program through the handle; locate and execute the main function of the target program based on the address of the main function of the target program; modify the pre-startup process name to the file name of the target program, and send a process end marker to the parent process.

[0101] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0102] This application provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of a memory management method. Compared with related technologies, this method effectively manages the memory usage of the target program by pre-starting a lightweight process and then running the main function of the target program through that lightweight process. This avoids situations where one or more programs request a large amount of memory at startup, but the CGroup technology fails to provide timely memory configuration and management, resulting in memory resource management failure.

[0103] In one alternative embodiment, an electronic device is provided, such as Figure 7 As shown, Figure 7 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0104] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0105] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0106] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0107] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0108] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0109] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0110] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0111] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0112] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A memory management method, characterized in that, include: Obtain the pre-start process and generate a client based on the pre-start process; The client sends the execution information of the target program to be launched to the pre-launch process. The pre-boot process performs memory management on the target program based on the execution information. The acquisition of the pre-startup process specifically includes: Start the parent process that provides the pre-startup process template; A pre-boot process is generated based on the parent process using kernel functions; wherein the pre-boot process is a child process of the parent process; The step of managing the memory of the target program based on the execution information through the pre-boot process specifically includes: The pre-boot process loads the target program's binary file into memory using the obtained file path; After loading is complete, obtain the handle returned by the target program; The target program is executed based on the handle.

2. The method according to claim 1, characterized in that, The step of sending the execution information of the target program to be launched to the pre-launch process through the client includes: The client obtains the execution information of the target program to be launched; The client sends the execution information of the target program to the pre-start process; the execution information includes the process identification number, file path, and file name.

3. The method according to claim 2, characterized in that, The step of managing the memory of the target program through the pre-boot process based on the execution information includes: If it is determined that the target program needs to be controlled, the process ID of the target program and the preset memory size received by the pre-boot process are written to the corresponding locations in the operating system kernel.

4. The method according to claim 1, characterized in that, The execution of the target program based on the handle includes: The address of the target program's main function is obtained through the handle; Locate and execute the main function of the target program based on its address; The pre-startup process name is changed to the file name of the target program, and a process end flag is sent to the parent process.

5. A memory resource management device, characterized in that, include: A startup module is used to obtain a pre-startup process and generate a client based on the pre-startup process; The information acquisition module is used to send the execution information of the target program to be launched to the pre-launch process through the client; The management module is used to manage the memory of the target program based on the execution information through the pre-startup process; The startup module is specifically used for: Start the parent process that provides the pre-startup process template; A pre-boot process is generated based on the parent process using kernel functions; wherein the pre-boot process is a child process of the parent process; The control module is specifically used for: The pre-boot process loads the target program's binary file into memory using the obtained file path; After loading is complete, obtain the handle returned by the target program; The target program is executed based on the handle.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-4.

Images