Program memory monitoring method, device, computer equipment and storage medium

Abstract

The present application relates to a program memory monitoring method, apparatus, computer equipment, storage medium and computer program product, wherein the method can effectively determine the creation source and destruction status of program script memory objects during program operation by determining information of program script backend objects from the creation process and the destruction process based on function call stack data in the creation process and destruction information in the destruction process, and can effectively determine the changes in program memory based on the managed heap memory information in the creation process, thereby effectively improving the monitoring effect of memory monitoring.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a program memory monitoring method, apparatus, computer equipment, storage medium and computer program product. Background Art

[0002] With the development of program development technology, various program development tools have also been continuously updated and evolved. For example, for game development technology, game engines, a development tool, play an increasingly important role in game development. Game engines refer to some pre-written editable computer game systems or core components of some interactive real-time graphics applications. These systems provide game designers with various tools needed to write games, with the aim of allowing game designers to easily and quickly make game programs without starting from scratch. Game engines include the following systems: rendering engine (i.e., "renderer", including two-dimensional graphics engine and three-dimensional graphics engine), physics engine, collision detection system, sound effects, script engine, computer animation, artificial intelligence, network engine, and scene management. Game projects developed based on game engines may face the problem of too high logical memory. At this time, memory monitoring can be used to determine the memory usage of the game, so as to analyze and optimize the memory.

[0003] At present, memory usage in a program can generally be captured through a memory capture tool during program development. For example, in the development of a game program, the game engine's built-in memory capture tool can be used to capture active objects in the current memory in the form of snapshots, and provide users with an instantaneous list of active object snapshots, thereby enabling game memory monitoring. However, this monitoring method can only provide a list of surviving objects in the memory, and users cannot obtain information about the source of object creation, so the memory monitoring effect is poor. Summary of the invention

[0004] Based on this, it is necessary to provide a program memory monitoring method, apparatus, computer equipment, computer-readable storage medium and computer program product that can improve the program memory monitoring effect in response to the above technical problems.

[0005] In a first aspect, the present application provides a program memory monitoring method. The method comprises:

[0006] Determine a program script backend object corresponding to the program, and read creation information and function call stack data corresponding to the program script backend object;

[0007] Based on the creation information, determining the managed heap memory information of the program script backend object;

[0008] Obtaining the destruction information of the program script backend object corresponding to the program;

[0009] A memory monitoring result corresponding to the program is obtained according to the managed heap memory information, the destruction information, and the function call stack data.

[0010] In a second aspect, the present application also provides a program memory monitoring device. The device comprises:

[0011] A creation information acquisition module is used to determine the program script backend object corresponding to the program, and read the creation information and function call stack data corresponding to the program script backend object;

[0012] A managed heap information acquisition module, used to determine the managed heap memory information of the program script backend object based on the creation information;

[0013] A destruction information acquisition module, used to obtain the destruction information of the program script backend object corresponding to the program;

[0014] The monitoring result acquisition module is used to obtain the memory monitoring result corresponding to the program according to the managed heap memory information, the destruction information and the function call stack data.

[0015] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0016] Determine a program script backend object corresponding to the program, and read creation information and function call stack data corresponding to the program script backend object;

[0017] Based on the creation information, determining the managed heap memory information of the program script backend object;

[0018] Obtaining the destruction information of the program script backend object corresponding to the program;

[0019] A memory monitoring result corresponding to the program is obtained according to the managed heap memory information, the destruction information, and the function call stack data.

[0020] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0021] Determine a program script backend object corresponding to the program, and read creation information and function call stack data corresponding to the program script backend object;

[0022] Based on the creation information, determining the managed heap memory information of the program script backend object;

[0023] Obtaining the destruction information of the program script backend object corresponding to the program;

[0024] A memory monitoring result corresponding to the program is obtained according to the managed heap memory information, the destruction information, and the function call stack data.

[0025] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0026] Determine a program script backend object corresponding to the program, and read creation information and function call stack data corresponding to the program script backend object;

[0027] Based on the creation information, determining the managed heap memory information of the program script backend object;

[0028] Obtaining the destruction information of the program script backend object corresponding to the program;

[0029] A memory monitoring result corresponding to the program is obtained according to the managed heap memory information, the destruction information, and the function call stack data.

[0030] The above-mentioned program memory monitoring method, device, computer equipment, storage medium and computer program product, wherein the method determines the program script backend object corresponding to the program, reads the creation information and function call stack data corresponding to the program script backend object; based on the creation information, determines the managed heap memory information of the program script backend object; obtains the destruction information of the program script backend object corresponding to the program; and obtains the memory monitoring result corresponding to the program based on the managed heap memory information, destruction information and function call stack data. The present application can effectively determine the creation source and destruction status of the program script memory object during the program running process by determining the information of the program script backend object from the creation process and the destruction process, based on the function call stack data in the creation process and the destruction information in the destruction process, and can effectively determine the program memory changes based on the managed heap memory information in the creation process, thereby effectively improving the monitoring effect of memory monitoring. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of a flow chart of a program memory monitoring method in one embodiment;

[0032] Figure 2 A schematic diagram of a process for determining managed heap memory information in one embodiment;

[0033] Figure 3 A flowchart of a step of obtaining destruction information of a program script backend object in one embodiment;

[0034] Figure 4 A flowchart of a step of obtaining destruction information of a program script backend object in another embodiment;

[0035] Figure 5 A schematic diagram of a data structure recorded in a disk in one embodiment;

[0036] Figure 6 A schematic flow chart of the steps of obtaining function call stack data of a program script backend object corresponding to a program in one embodiment;

[0037] Figure 7 A schematic diagram of a stack backtracking step in one embodiment;

[0038] Figure 8 A schematic diagram of a compression process of a function call stack in one embodiment;

[0039] Fig. 9 A flowchart of an object creation process and a monitoring and recording process in one embodiment;

[0040] Fig.10 A schematic diagram of a process of calling address information restoration in one embodiment;

[0041] Fig.11 A schematic diagram of a process for generating visual report page data in one embodiment;

[0042] Fig.12 A flowchart of a process for displaying memory monitoring results in one embodiment;

[0043] Fig.13 A flowchart of a program memory monitoring method implemented in a mobile terminal according to an embodiment;

[0044] Fig.14 A schematic diagram of visually displaying memory monitoring results in one embodiment;

[0045] Fig.15 is a structural block diagram of a program memory monitoring device in one embodiment;

[0046] Fig.16 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] like Figure 1As shown, a program memory monitoring method is provided. This embodiment takes the method applied to a terminal as an example. It can be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0049] Step 102, determining the program script backend object corresponding to the program, and reading the creation information and function call stack data corresponding to the program script backend object.

[0050] Among them, the program is the monitoring object of the program memory monitoring method of the present application. In a specific embodiment, the program of the present application may specifically include client games on terminals such as mobile terminals or host terminals, and these games are generally developed based on game engines. During the running of the game, the logical memory occupied by the game is constantly changing. The program script backend object specifically refers to the object created by the program during the running process. For example, for a game developed based on the unity engine, its program script backend object can be an il2cpp object. il2cpp is a script backend developed by unity, which can replace Mono when building projects for various platforms. When using il2cpp to build a project, the unity engine converts the IL code in the script and assembly to C++ before creating a native binary file (such as apk) for the selected platform. During the running of the game, the object created based on the il2cpp script backend is the il2cpp object, that is, the program script backend object in the present application scheme. Creation information specifically refers to information such as the type, size, and address corresponding to the program script backend object. Function call stack data is used to record function call information of the program script backend object during the creation process.

[0051] Specifically, the program memory monitoring method of the present application can be used to monitor the changes in logical memory (virtual memory) during the program running process on the terminal. When the program on the terminal system is started, the program memory monitoring method of the present application can be used to implement monitoring. During the program running process, the original code of the program will be converted by the program script backend into code that can be run on the terminal, and the corresponding program script backend object will be created in the logical memory of the terminal. The terminal can record the creation information and function call stack data of the program corresponding to the program script backend object based on the program memory monitoring method of the present application during the running process after the program is started. Among them, recording the creation information of the program corresponding to the program script backend object can be decomposed into the establishment of each basic type of object. For example, for the il2cpp object, the key technical point of recording the creation of the il2cpp object is to find a logical point that can cover the creation of all il2cpp objects. By analyzing the il2cpp virtual machine, it can be seen that the creation of all il2cpp objects will be converged and summarized into three basic types of creation, which are Object, Array, and String. Therefore, the recording of the creation information of the program script backend object can be realized by recording the three types of basic objects. The function call stack data can be used to efficiently locate the creation source of the object. The function call stack data can be obtained through the stack backtracing mechanism.

[0052] Step 104: Determine the managed heap memory information of the program script backend object based on the creation information.

[0053] The managed heap refers to the memory managed heap, which can pre-apply for a certain number of memory blocks for backup before actually using the memory. When there is a new memory demand, a part of the memory blocks will be allocated from the memory pool for use. If the memory blocks are not enough, new memory will be applied for.

[0054] Specifically, during the program running process, the managed heap corresponding to the program will change due to the creation of the program script backend object. Therefore, after each program script backend object is created, the size, type, address, and function call stack of the object allocated during this creation process can be recorded. At the same time, the size of the managed heap at this time will be called and recorded together to obtain the managed heap memory information of the program script backend object. By recording the changes in the managed heap during the creation of each program script backend object, the program memory changes can be effectively monitored.

[0055] Step 106, obtaining the destruction information of the program script backend object corresponding to the program.

[0056] Among them, the destruction information refers to the information of the program script backend object destroyed during the program running process, specifically including the object address of the program script backend object. When the program script backend object is not referenced by the business processing logic during the program running process, the destruction operation can be executed to destroy it. At the same time, during the destruction process of the program script backend object, the object address of the program script backend object to be destroyed can be recorded for use when the subsequent tool chain restores the memory usage.

[0057] Specifically, during the program running process, it not only includes the creation process of the program script backend object, but also includes the destruction process of the corresponding object. In each program script backend object, the terminal can record the corresponding destruction information based on the program memory monitoring method of the present application, and further determine the memory usage changes during the destruction process of the program script backend object.

[0058] Step 108, obtaining the memory monitoring result corresponding to the program according to the managed heap memory information, destruction information and function call stack data.

[0059] The memory monitoring result may specifically be a visual display of memory changes during program execution, including a display of memory changes in the managed heap and a display of function call stack addresses.

[0060] Specifically, after the terminal obtains the managed heap memory information, destruction information and function call stack data from the process of program running, it can generate the memory monitoring results during the program running process based on all the managed heap memory information, destruction information and function call stack data. From the start of the program to the end of the program, each program script backend object has a managed heap memory information and function call stack data corresponding to it when it is created, and each program script backend object has a destruction information corresponding to it when it is destroyed. By recording the time nodes of the managed heap memory information, destruction information and function call stack data, the reasons for the program memory changes can be effectively analyzed, thereby generating visual memory monitoring results and displaying them to the user. In one embodiment, the memory changes during the program running process can be displayed in the form of a web page by using python to generate a web page.

[0061] The above-mentioned program memory monitoring method determines the program script backend object corresponding to the program, reads the creation information and function call stack data corresponding to the program script backend object; based on the creation information, determines the managed heap memory information of the program script backend object; obtains the destruction information of the program script backend object corresponding to the program; and obtains the memory monitoring result corresponding to the program according to the managed heap memory information, the destruction information and the function call stack data. The present application can effectively determine the creation source and destruction of the program script memory object during the program running process by determining the information of the program script backend object from the creation process and the destruction process, based on the function call stack data in the creation process and the destruction information in the destruction process, and can effectively determine the program memory change situation based on the managed heap memory information in the creation process, so as to effectively improve the monitoring effect of memory monitoring. The scheme of the present application can efficiently grasp the usage of managed heap memory when the program is running, greatly improve the efficiency of managed heap memory analysis and managed heap memory optimization. In one embodiment, the program memory monitoring method of the present application can also be integrated into the automated pipeline for performance testing of the game, so as to realize continuous monitoring and automated reporting of the managed heap memory occupancy of the game, prevent problems before they happen, and greatly reduce the performance risks caused by the increase of managed heap memory.

[0062] In one embodiment, if Figure 2 As shown, step 104 includes:

[0063] Step 201, obtaining object size information, object type information and object address information in the creation information.

[0064] Step 203: Call a preset managed heap size acquisition function to acquire managed heap size information.

[0065] Step 205, determining the managed heap memory information of the program script backend object according to the object size information, the object type information, the object address information and the managed heap size information.

[0066] Among them, the object size information, object type information and object address information are used to describe the memory size occupied by the program script backend object, the type of the object and the address of the object respectively. The preset managed heap size acquisition function is a function specifically used to obtain the memory size occupied by the managed heap at the current moment. When the program is running, if a new program script backend object needs to be created, new memory requirements may be generated during creation. At this time, a part of the memory block can be allocated from the memory pool of the memory managed heap for use. If the memory block is not enough, new memory can be applied for. At this time, the memory size of the managed heap corresponding to the program will change. That time, when creating a new program script backend object, you can call the preset managed heap size acquisition function to obtain the managed heap size information at the current moment.

[0067] Specifically, when the program script backend object is created, in addition to recording the creation information of the program script backend object, the present application determines the managed heap memory information of the program script backend object based on the creation information, thereby completely recording the creation process of each il2cpp object and obtaining the most complete memory allocation information. In one embodiment, the program of the present application is specifically a game program, which is developed based on the unity engine. At this time, the program script backend object is specifically an il2cpp object. By analyzing the il2cpp virtual machine, it can be known that the creation of all il2cpp objects will be converged and summarized into three basic types of creation, which are Object, Array, and String. Therefore, the size and address of the objects under the three types of Object, Array, and String can be recorded respectively, and the object size information, object type information, and object address information in the creation information can be obtained. At the same time, the size of the managed heap at this time can be obtained by presetting the managed heap size acquisition function scripting_gc_get_heap_size. Then, based on the object size information, object type information, object address information, and managed heap size information, the change of managed heap memory allocation and the change of managed heap size at the current moment are determined to obtain the managed heap memory information. In this embodiment, by determining the size, type and address of the program script backend object created during the program running process, and identifying the size change of the memory managed heap when the program script backend object is created, it is possible to effectively monitor the memory changes during the creation of the program script backend object and ensure the monitoring effect.

[0068] In one embodiment, if Figure 3 As shown, step 106 includes:

[0069] Step 302: traverse all program script backend objects in the managed heap using a preset garbage collection algorithm to determine program script backend objects that are not referenced by program business logic.

[0070] Step 304: Record the object address of the program script backend object that is not referenced by the program business logic through a preset callback function, and obtain the destruction information of the program script backend object.

[0071] Step 306: Destroy the program script backend objects that are not referenced by the program business logic.

[0072] Among them, the preset garbage collection algorithm refers to an algorithm for memory management during program operation, which can be automatically started when the program occupies a preset threshold, or manually started by the developer through instructions. The preset garbage collection algorithm can identify program script backend objects that are not referenced by the program business logic, and then destroy them. The callback function is a function passed as a parameter. In this embodiment, the address of the program script backend object to be destroyed is mainly recorded through the callback function for subsequent use in restoring memory usage.

[0073] Specifically, during the running of the program, the garbage collection algorithm can be used to traverse all surviving program script backend objects, find out the program script backend objects that are not referenced by the business logic, and then perform the destruction operation. At the same time, before the destruction logic is actually executed, a callback function will be executed, and the object address of the program script backend object to be destroyed will be recorded through the callback function for subsequent use in restoring memory usage. After the recording is completed, the destruction process of the object is executed normally. In one embodiment, the program script backend object is specifically an il2cpp object. At this time, the process of object destruction can refer to Figure 4 As shown in the figure, first, by starting the garbage collection algorithm, traversing all the live objects, and then searching for objects that are not referenced by the business logic, prepare to execute the recycling, and execute the callback before the recycling execution, record the address of the recycled object, and then recycle and release the memory. The data structure recorded to the disk can be referred to Figure 5 As shown, Figure 5 As shown, three objects A, B and C are created in sequence. During the creation process, the corresponding object size information, object address information, function call stack and managed heap size are recorded respectively. Then, during the destruction process, three objects C, B and A are destroyed in sequence and the object addresses are recorded. In this implementation, the destruction operation of the program script backend object and the object address of the destroyed program script backend object are executed through the garbage collection algorithm and the callback function, so as to realize the memory monitoring of the object destruction process.

[0074] In one embodiment, if Figure 6 As shown, the function call stack data of the program script backend object corresponding to the program in step 102 includes:

[0075] Step 601, obtaining the call address information corresponding to the function call stack through the stack backtracking mechanism.

[0076] Step 603, compressing the call address information by using an information indexing method, and obtaining function call stack data of a program script backend object corresponding to the program.

[0077] The stack backtrace mechanism refers to the frame pointer mechanism, which is a fast unwind stack backtrace mechanism. Its principle is to record the caller's address into the fp register when the compiler generates assembly, so that the stack backtrace process becomes a very efficient register value chain reading operation. The schematic diagram of the stack backtrace can be referred to Figure 7 , stack backtracing can be effectively implemented through the FP register (caller FP). The information index rule refers to a method of compressing the function call stack. The information index rule will try to find whether there is the same stack string in the list. If found, it will directly return the index value of the stack string in the list; if not found, the tool will store the stack string in this list, and then return the index value of the stack string in the list. Using this compression method, a binary function address string with a length of 8 in a 64-bit system can be compressed into an index value with a length of 1. And during the recording process, if the same binary function address appears n times, it will only be stored once and recorded with the same index. The specific compression process of the function call stack can be referred to. Figure 8 The obtained function call stack data may specifically be an index list corresponding to the call address information.

[0078] Specifically, the solution of the present application will not only record the creation information of the program script backend object, but also record the function call stack at the time of object creation, so as to help users efficiently locate the source of object creation. Among them, the collection of function call stack information can be carried out through the stack backtracking mechanism. By using the stack backtracking mechanism when the object is created, the call address information corresponding to the function call stack can be effectively obtained. However, if the function call stack is directly stored in the program project, the memory and disk occupancy will be very large. At the same time, the applicant found that the characteristic of the function call stack is that the same function address may appear repeatedly with high frequency. According to this feature, the present application compresses the function call stack information to be recorded by using the information indexing method, thereby obtaining the function call stack data of the program script backend object. In a specific embodiment, the program script backend object in the present application is specifically an il2cpp object. At this time, the object creation process and the monitoring and recording process can be specifically referred to. Fig. 9As shown, first create an il2cpp object, and after the creation is completed, you can start backtracing the call stack. Then perform an identification to determine whether the backtraced address exceeds the address range that needs to be recorded. If it does not exceed, determine to continue backtracing. After exceeding, the backtraced function call stack can be recorded, and the call stack address list can be compressed. The index list is generated by the information indexing method, and the index list and the object memory address and memory size of each type of object are recorded. Finally, the managed heap size acquisition function is preset to obtain the managed heap size information, and the memory monitoring during the object creation process is completed. In this embodiment, the stack backtracing mechanism and the information indexing method can effectively record the function call stack data during the program script backend object creation process, thereby achieving more effective memory monitoring.

[0079] In one embodiment, if Fig.10 As shown, step 108 includes:

[0080] Step 1001, restore the function call stack data to obtain a binary form of the function call stack address list.

[0081] Step 1003: restore the binary function call stack address list to call address information through a preset symbol table.

[0082] Step 1005, obtaining the memory monitoring result corresponding to the program according to the managed heap memory information, destruction information and call address information.

[0083] Among them, after compressing the call address information through the information indexing method, it is necessary to perform the corresponding decompression operation to restore the compressed call address information to ensure its readability. The decompression process is equivalent to the inverse process of the compression process. It is necessary to first restore the index table obtained after compression, obtain the binary function call stack address list, and then restore the binary function call stack address list to the call address information. The memory monitoring result refers to the display of memory changes during program operation in a visual form. The managed heap memory information, destruction information and call address information can effectively display the memory changes during each program script backend object creation process.

[0084] Specifically, after obtaining the managed heap memory information, destruction information, and function call stack data during program execution, in order to more intuitively display the memory monitoring results to external users, the compressed function call stack data can be decompressed first. This process requires first restoring the function call stack data in the form of an index list to obtain a binary function call stack address list; the binary function call stack address list is restored to the original more intuitive call address information through a preset symbol table. Then, based on the managed heap memory information, destruction information, and call address information, a memory monitoring result can be generated for display to the user. In this embodiment, by restoring the function call stack data to the call address information, and then displaying the memory monitoring results based on the managed heap memory information, destruction information, and call address information, the changes during program execution can be more intuitively displayed to the user, while helping the user to efficiently locate the creation source of the object and the destruction process of the object.

[0085] In one embodiment, the memory monitoring results include visual report page data, such as Fig.11 As shown, step 1005 includes:

[0086] 1102. Generate a hierarchical managed heap memory allocation information report and a managed heap memory change curve chart based on the managed heap memory information.

[0087] 1104 , generating visual report page data according to the destruction information, the call address information, the managed heap memory allocation information report, and the managed heap memory change curve chart.

[0088] Among them, the managed heap memory allocation information report and the managed heap memory change curve are both chart data that intuitively display the memory changes during the program running process. The managed heap memory allocation information report can be in the form of hierarchy, while the managed heap memory change curve is in the form of echarts. The visual report page refers to the summary and display of the above-mentioned destruction information, call address information, managed heap memory allocation information report, and managed heap memory change curve through the page. Users can determine the managed heap memory changes during the creation of the program script backend object at each time node during the program running process based on the visual report page.

[0089] Specifically, during the program running process, with the creation and destruction of the program script backend object, the managed heap memory information is constantly changing, and the purpose of program memory monitoring is to record the change process of memory information. Therefore, the program memory monitoring method of the present application, during the program running process, when each program script backend object is created, it is necessary to record the corresponding creation information and function call stack data, and further determine the corresponding managed heap memory information, monitor the memory changes of the managed heap when each program script backend object is created, and mainly determine which objects need to apply for additional memory when the managed heap is created. At the same time, in this process, the function call stack data can be used to efficiently locate the creation source of the object, and the object traceability in the monitoring process can be realized. Then, when each program script backend object is destroyed, the object address of the program script backend object to be destroyed can also be recorded, providing an additional layer of reference for program memory monitoring. The managed heap memory information can then be used to generate a hierarchical managed heap memory allocation information report and a managed heap memory change curve. The managed heap memory information includes the time nodes when each program script backend object was created, the size of the managed heap at the time of creation, the object address of each basic object, and the object size. Through the managed heap memory allocation information report and the managed heap memory change curve, the allocation of managed heap memory and the change of managed heap memory size during program operation can be effectively displayed. Then, based on these reports, combined with the call address when the object was created and the destruction information when the object was destroyed, visual report page data is generated, which can more intuitively display the memory changes during program operation and the source of the program script backend objects that caused the memory changes. In one embodiment, the display process of the memory monitoring results can refer to Fig.12 As shown, in this process, the binary function call stack is first compressed through the index table to obtain the binary function call stack address list; then the binary function call stack address list is restored to the call address information through the preset symbol table. Then the processed recording data is loaded, including the managed heap memory information, destruction information and decompressed function call stack data, and a managed heap memory change curve in the form of echarts and a managed heap memory allocation information report in the form of hierarchy are generated, and then converted into a web page in html format and written to the disk to display it to the user. In one embodiment, Fig.13As shown, the monitoring process of the program memory monitoring method of the present application is implemented on the mobile terminal, and the result display process is implemented on the PC. First, the original monitoring result is obtained on the mobile terminal, and then the original monitoring result is pulled to the PC, and then it is converted into a visual web page and then displayed on the PC. In this embodiment, the memory monitoring results during the game operation are displayed by generating a hierarchical managed heap memory allocation information report and a managed heap memory change curve chart, which can more intuitively display the memory monitoring results to the user and ensure the effect of program memory monitoring.

[0090] The present application also provides an application scenario, and the application scenario applies the above-mentioned program memory monitoring method. Specifically, the application of the program memory monitoring method in the application scenario is as follows:

[0091] When a user is developing a MOBA (Multiplayer Online Battle Arena) mobile game, it is necessary to determine the memory changes of the game program during operation. At this time, the program memory monitoring method of this application can be used on the terminal where the mobile game is installed to monitor the program memory. The mobile game is specifically developed through the unity game engine, and the program script backend object is specifically an il2cpp object. The terminal can obtain the virtual memory changes corresponding to the mobile game program during the time period when the mobile game program is running. The implementation of the scheme of this application specifically includes two processes, including the monitoring and recording of memory data when the program is running and the visual conversion of the recorded data. Among them, the monitoring and recording step of the memory data when the program is running refers to the real-time recording of each creation and destruction of the il2cpp object during the running of the game as a data source for performance analysis. The step of visual conversion of recorded data refers to the process of converting the obtained recorded data into a visual web page through a tool, presenting clear results to the user. Specifically, in the step of monitoring and recording the memory data when the program is running, it is first necessary to record the size, address and function call stack of the object allocation each time the il2cpp object is created. Because the creation of all il2cpp objects will be converged and summarized into the creation of three basic types, namely Object, Array, and String, the creation information corresponding to the backend objects of the program script can be recorded by recording the creation of the three basic types of objects respectively. For the function call stack data, the stack backtracking mechanism of the frame pointer can be used to achieve it. It records the address of the caller into the fp register when the compiler generates the assembly, thereby turning the stack backtracking process into an efficient register value chain reading operation. After obtaining the function call stack, if the function call stack is directly stored, the memory and disk usage will be very large. The characteristic of the function call stack is that the same function address may appear repeatedly with high frequency. According to this characteristic, the information index method can be used to compress the function call stack information to be recorded. After the function call stack is compressed, the size, type, address, and function call stack of the currently allocated ill2cpp object can be recorded. At the same time, the preset managed heap size acquisition function scripting_gc_get_heap_size will be called to obtain the size of the managed heap at this time and record it together. Then, after the il2cpp object is created, it is placed in the managed heap. When the memory of the managed heap needs to be released, the managed heap can traverse all living objects through the preset garbage collection algorithm, find the il2cpp objects that are not referenced by the game's business logic, and then destroy them.Before the destruction logic is actually executed, a callback function will be executed. In this embodiment, the address of the il2cpp object to be destroyed can be recorded in the callback function to obtain the destruction information for use when the subsequent tool chain restores the memory usage. After the recording is completed, the destruction process of the object is executed normally. When the runtime recording step is completed, the unreadable original result data is recorded. The next step is to use the tool to perform a visual conversion on the original result data. Through the index table of the information indexing method, the compressed and stored function call stack index list is restored to a binary function call stack address list. Then, in combination with the symbol table of il2cpp and unity, the binary function call stack address is restored to a readable function name. Next, you can also use python to generate a web page, including a memory allocation information report in the form of a hierarchy and a curve chart trend in the managed heap memory during the test process, to present the visualization results to the user. The final visualization display diagram can be specifically referenced. Fig.14 As shown, Fig.14 The upper middle part is a graph of the managed heap memory during the test process. Fig.14 The lower middle part is a memory allocation information report in hierarchy form.

[0092] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0093] Based on the same inventive concept, the embodiment of the present application also provides a program memory monitoring device for implementing the program memory monitoring method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more program memory monitoring device embodiments provided below can refer to the limitations of the program memory monitoring method above, and will not be repeated here.

[0094] In one embodiment, Fig.14 As shown, a program memory monitoring device is provided, comprising:

[0095] The creation information acquisition module 1502 is used to determine the program script backend object corresponding to the program, and read the creation information and function call stack data corresponding to the program script backend object.

[0096] The managed heap information acquisition module 1504 is used to determine the managed heap memory information of the program script backend object based on the creation information.

[0097] The destruction information acquisition module 1506 is used to obtain the destruction information of the program script backend object corresponding to the program.

[0098] The monitoring result acquisition module 1508 is used to obtain the memory monitoring result corresponding to the program according to the managed heap memory information, destruction information and function call stack data.

[0099] In one of the embodiments, the managed heap information acquisition module 1504 is specifically used to: obtain object size information, object type information and object address information in the creation information; call a preset managed heap size acquisition function to obtain managed heap size information; and determine the managed heap memory information of the program script backend object based on the object size information, object type information, object address information and managed heap size information.

[0100] In one of the embodiments, the destruction information acquisition module 1506 is specifically used to: traverse all program script backend objects in the managed heap through a preset garbage collection algorithm to determine the program script backend objects that are not referenced by the program business logic; record the object addresses of the program script backend objects that are not referenced by the program business logic through a preset callback function, obtain the destruction information of the program script backend objects, and perform destruction operations on the program script backend objects that are not referenced by the program business logic.

[0101] In one embodiment, the creation information acquisition module 1502 is specifically used to: obtain the call address information corresponding to the function call stack through the stack backtracking mechanism; compress the call address information through the information indexing method to obtain the function call stack data of the program script backend object corresponding to the program.

[0102] In one of the embodiments, the monitoring result acquisition module 1508 is specifically used to: restore the function call stack data to obtain a function call stack address list in binary form; restore the binary function call stack address list to call address information through a preset symbol table; and obtain the memory monitoring result corresponding to the program based on the managed heap memory information, destruction information, and call address information.

[0103] In one of the embodiments, the monitoring result acquisition module 1508 is also used to: generate a hierarchical managed heap memory allocation information report and a managed heap memory change curve chart based on the managed heap memory information; generate visual report page data based on the destruction information, call address information, the managed heap memory allocation information report and the managed heap memory change curve chart.

[0104] Each module in the above-mentioned program memory monitoring device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module above.

[0105] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig.16 As shown. The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a program memory monitoring method is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covered on the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

[0106] Those skilled in the art will understand that Fig.16 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0107] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0108] In one embodiment, a computer-readable storage medium is provided, storing a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0109] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in the above-mentioned method embodiments.

[0110] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0111] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0112] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0113] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A program memory monitoring method, characterized in that: The method comprises: Determine the program script backend object corresponding to the program, read the creation information and function call stack data corresponding to the program script backend object, the function call stack data obtains the call address information corresponding to the function call stack by the stack backtracking mechanism; and compresses the call address information by the information indexing method; Based on the creation information, determining the managed heap memory information of the program script backend object; Obtaining the destruction information of the program script backend object corresponding to the program; Restoring the function call stack data to obtain a function call stack address list in binary form; Restore the binary function call stack address list to call address information through a preset symbol table; A memory monitoring result corresponding to the program is obtained according to the managed heap memory information, the destruction information, and the calling address information.

2. The method according to claim 1, characterized in that Determining the managed heap memory information of the program script backend object based on the creation information includes: Obtaining object size information, object type information, and object address information in the creation information; Call the preset managed heap size acquisition function to obtain the managed heap size information; The managed heap memory information of the program script backend object is determined according to the object size information, the object type information, the object address information and the managed heap size information.

3. The method according to claim 1, characterized in that The obtaining of the destruction information of the program script backend object corresponding to the program includes: Traverse all program script backend objects in the managed heap through a preset garbage collection algorithm to determine program script backend objects that are not referenced by program business logic; Obtaining destruction information of the program script backend object by presetting a callback function and recording the object address of the program script backend object that is not referenced by the program business logic; After obtaining the destruction information of the program script backend object corresponding to the program, the method further includes: A destruction operation is performed on the program script backend object that is not referenced by the program business logic.

4. The method according to claim 1, characterized in that: The memory monitoring result includes visual report page data, and obtaining the memory monitoring result corresponding to the program according to the managed heap memory information, the destruction information, and the call address information includes: Based on the managed heap memory information, generate a hierarchical managed heap memory allocation information report and a managed heap memory change curve graph; Visual report page data is generated according to the destruction information, the call address information, the managed heap memory allocation information report, and the managed heap memory change curve chart.

5. A program memory monitoring device, characterized in that: The device comprises: A creation information acquisition module is used to determine the program script backend object corresponding to the program, read the creation information and function call stack data corresponding to the program script backend object, the function call stack data is obtained by the stack backtracking mechanism to obtain the call address information corresponding to the function call stack; and the call address information is obtained by compressing it through the information indexing method; A managed heap information acquisition module, used to determine the managed heap memory information of the program script backend object based on the creation information; A destruction information acquisition module, used to obtain the destruction information of the program script backend object corresponding to the program; A monitoring result acquisition module is used to restore the function call stack data to obtain a function call stack address list in binary form; restore the function call stack address list in binary form to call address information through a preset symbol table; and obtain the memory monitoring result corresponding to the program based on the managed heap memory information, the destruction information and the call address information.

6. The device according to claim 5, characterized in that The managed heap information acquisition module is specifically used to: obtain the object size information, object type information and object address information in the creation information; call a preset managed heap size acquisition function to obtain the managed heap size information; and determine the managed heap memory information of the program script backend object based on the object size information, object type information, object address information and managed heap size information.

7. The device according to claim 5, characterized in that The destruction information acquisition module is specifically used to: traverse all program script backend objects in the managed heap through a preset garbage collection algorithm to determine the program script backend objects that are not referenced by the program business logic; obtain the destruction information of the program script backend objects through a preset callback function and recording the object addresses of the program script backend objects that are not referenced by the program business logic; and perform a destruction operation on the program script backend objects that are not referenced by the program business logic.

8. The device according to claim 5, characterized in that The monitoring result acquisition module is also used to: generate a hierarchical managed heap memory allocation information report and a managed heap memory change curve chart based on the managed heap memory information; generate visual report page data according to the destruction information, the call address information, the managed heap memory allocation information report and the managed heap memory change curve chart.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 4 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

Images