Operator load collection method and apparatus, and computing device and storage medium

Abstract

The present application relates to the technical field of computers. Disclosed are an operator load collection method and apparatus, and a computing device and a storage medium. The method comprises: acquiring a target instruction stream during the runtime of a target code, wherein the target instruction stream comprises an instruction identifier, which represents a virtual address of the next CPU instruction to be executed; acquiring a virtual address of a target function operator invoked during the runtime of the target code; and on the basis of the virtual address of the target function operator and the instruction identifier, determining from the target instruction stream a first CPU instruction corresponding to the target function operator, and on the basis of the first CPU instruction, obtaining a CPU instruction set corresponding to the target function operator, wherein an operator load comprises the target instruction stream and the CPU instruction set corresponding to the target function operator. The method can simultaneously acquire coarse-grained function-level traces and fine-grained instruction-level traces under a plurality of architectures, thereby meeting the requirements for coarse-grained and fine-grained performance optimization of a target code, and thus realizing macroscopic and microscopic performance analysis of the target code.

Description

Operator load acquisition method, device, computing equipment and storage medium

[0001] This application claims priority to Chinese Patent Application No. 202411759265.X, filed on November 29, 2024, entitled “Operator Load Acquisition Method, Apparatus, Computing Device and Storage Medium”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to an operator load acquisition method, apparatus, computing device, and storage medium. Background Technology

[0003] Modern internet services are typically implemented using complex, large-scale distributed clusters, built on software modules developed by different teams using different programming languages. Interactions between multiple nodes and processes are complex, with frequent data flow. Simple instruction-level tracing is insufficient to fully depict the complex interactions between different software modules and hardware devices, and the order of instruction-level traces in end-to-end internet applications is enormous. In this context, the need for load slicing targeting hotspot / bottleneck functions has emerged. Understanding the performance changes of hotspot / bottleneck functions helps in understanding the overall internet application. However, coarse-grained function-level tracing does not support fine-grained performance optimization. Summary of the Invention

[0004] The purpose of this application is to provide an operator load acquisition method, apparatus, computing device, and storage medium that can simultaneously acquire coarse-grained function-level traces and fine-grained instruction-level traces under multiple architectures, thereby meeting the requirements for coarse-grained and fine-grained performance optimization of target code, and thus realizing macroscopic and microscopic performance analysis of target code.

[0005] To achieve the above objectives, the embodiments of this application provide the following solutions:

[0006] Firstly, this application provides an operator load acquisition method, comprising: acquiring a target instruction stream during the execution of target code, the target instruction stream including an instruction identifier, the instruction identifier representing the virtual address of the next CPU instruction to be executed; acquiring the virtual address of a target function operator called during the execution of the target code; determining the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address of the target function operator and the instruction identifier, and obtaining the CPU instruction set corresponding to the target function operator based on the first CPU instruction. The operator load includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

[0007] By using the instruction identifier of the target instruction stream and the virtual address of the target function operator, the first CPU instruction corresponding to the target function operator can be accurately determined from the target instruction stream. Starting from this point, the complete set of CPU instructions corresponding to the target function operator can be obtained, achieving both coarse-grained function-level trace and fine-grained instruction-level trace acquisition. This is because, on the one hand, the target instruction stream itself constitutes a fine-grained instruction-level trace, clearly defining the specific instruction execution within the target instruction stream, allowing for in-depth understanding of the micro-execution details within the target code; on the other hand, the set of CPU instructions corresponding to the target function operator constitutes a coarse-grained function-level trace, macroscopically displaying the execution path of the program corresponding to the target code, the call relationships between different functions within the target function operator, and execution time, etc. Thus, this application embodiment does not limit the specific architecture; for multiple different architectures, it can simultaneously achieve the acquisition of coarse-grained function-level trace and fine-grained instruction-level trace, fusing the collected operator load to meet the needs of different levels of performance optimization, realizing macro- and micro-level performance analysis of the target code, and breaking through the limitations in in-depth mining and optimization of application performance.

[0008] In one possible implementation, determining the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator includes: identifying the target instruction identifier in the target instruction stream that has the same starting virtual address as the target function operator; and determining the CPU instruction corresponding to the target instruction identifier as the first CPU instruction corresponding to the target function operator.

[0009] By matching the starting virtual address of the target function operator with the instruction identifier in the target instruction stream, the first CPU instruction corresponding to the target function operator can be accurately traced from the target instruction stream. This enables precise location of the starting instruction of each target function operator, breaks down the barrier between instruction-level trace and function-level trace, and aligns the target function operator at the beginning of the target instruction stream (i.e., the position of the first CPU instruction), thereby achieving precise location and analysis of the target function operator.

[0010] In one possible implementation, obtaining the CPU instruction set corresponding to the target function operator based on the first CPU instruction includes: tracing function jump instructions and function return instructions in the target instruction stream based on the first CPU instruction. Function jump instructions indicate a jump to the function to be called, and function return instructions indicate the end of the called function. The function jump instructions and function return instructions are then paired. The CPU instructions between the first CPU instruction and the unpaired function return instructions are taken as the CPU instruction set corresponding to the target function operator.

[0011] By tracing and pairing function jump and return instructions in the target instruction stream based on the first CPU instruction, the sub-function operators called by the target function operator can be traced. For example, every two successfully paired function jump and return instructions are identified as a sub-function operator. During the tracing of sub-function operators, the sub-function call stack (including sub-function call relationships) can be clearly identified. Based on this, unpaired function return instructions are identified as the end of the target function operator. In this way, the barrier between instruction-level trace and function-level trace is broken down, aligning the function at the end of the instruction stream (i.e., unpaired function return instructions). This allows for precise acquisition of the CPU instruction set corresponding to the target function operator, obtaining a coarse-grained function-level trace from a macroscopic scale. This enables in-depth analysis of the internal logic flow of the target function operator during execution, and thus accurate evaluation of its behavior and performance.

[0012] In one possible implementation, obtaining the virtual address of the target function operator called by the target code at runtime includes: obtaining the starting virtual address of the target library from the target memory-mapped file. The target memory-mapped file records memory mapping information when the virtual machine runs the target code, and the target library represents the library called by the target code at runtime. The target library includes the target function operator. The offset of the function operator in the target library is obtained from the .so file. Based on the starting virtual address of the target library and the offset of the function operator in the target library, the virtual address of the function operator in the target library is determined. Thus, when the target code runs, the called lib.so file is named the target library, associating the .so file with the target library, thereby establishing an effective mapping relationship between the code and data structures at the physical storage level and the virtual memory space of the process at runtime. The starting virtual address of the target library recorded in the process's / proc / pid / maps file allows for precise tracking of the target library's location in virtual memory.

[0013] In one possible implementation, determining the virtual address of a function operator in the target library based on its starting virtual address and the offset of the function operator within the target library involves using the sum of the starting virtual address and the offset of the function operator as the virtual address of the function operator. Since the relative position of the function operator in the target library remains unchanged regardless of whether it exists in physical or virtual memory, using the sum of the starting virtual address and the function operator's offset to determine the virtual address allows for quick and accurate location of the target function operator's virtual address in the virtual memory space during the execution of the target code.

[0014] In one possible implementation, obtaining the target instruction stream during target code runtime includes: inserting preset marker instructions before the first line of code and after the last line of code in the target code. These preset marker instructions are used by the virtual machine to identify intervals within the target code during execution. The target code with the preset marker instructions inserted is then run by the virtual machine to obtain the target instruction stream output by the virtual machine.

[0015] By inserting pre-marking instructions before and after the target code and running the instrumented target code using a virtual machine, this approach achieves two goals: First, it preserves the original code structure and logic, allowing the virtual machine to accurately define target code regions and obtain the target instruction stream output by the virtual machine during execution without interfering with the normal operation of the target code. This target instruction stream reflects the execution of each CPU instruction, thus accurately reflecting the fine-grained behavior and performance of the target code. Second, since the virtual machine is not limited by a specific architecture, it can run code from various architectures, thereby obtaining target instruction streams from different architectures. This enables operator load acquisition from any GPL-licensed emulator (Quick Emulator, QEMU) architecture (e.g., X86, ARM, AARCH64), allowing for in-depth research and performance evaluation of target code in diverse programming environments.

[0016] In one possible implementation, the method further includes: obtaining a snapshot of the system registers corresponding to the target code, whereby the snapshot of the system registers corresponding to the target code is used to represent the system state at the moment when the target code starts running.

[0017] By acquiring a system snapshot representing the moment the target code begins execution, it is possible to quickly jump to that runtime system state, thereby enabling precise reproduction of the initial environment of the target code's execution when needed (e.g., in the application scenario of simulator simulating and replaying operator loads). This allows for in-depth analysis of problems during the execution of the target code, performance optimization (such as performance tuning of operator loads, scheduling optimization of the system where the load resides, etc.), verification of system behavior, and exploration of the system's hardware and software co-architecture.

[0018] Secondly, this application provides an operator load acquisition device, comprising: a first acquisition module, configured to acquire the target instruction stream of target code during runtime, the target instruction stream including an instruction identifier, the instruction identifier representing the virtual address of the next CPU instruction to be executed; a second acquisition module, configured to acquire the virtual address of a target function operator called during runtime of the target code; and a third acquisition module, configured to determine the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator, and obtain the CPU instruction set corresponding to the target function operator based on the first CPU instruction. The operator load includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

[0019] Thirdly, this application provides a computing device, including: a processor and a memory for storing processor-executable instructions. When the processor is configured to execute instructions, the computing device implements the operator load acquisition method described above.

[0020] Fourthly, this application provides a storage medium storing computer program instructions thereon; when the computer program instructions are executed by a computing device, the computing device implements the operator load acquisition method described above.

[0021] Fifthly, this application provides a program product including a computer-readable storage medium storing a computer program, which, when at least one processor executes the computer program, causes at least one processor to execute the above-described operator load acquisition method. Attached Figure Description

[0022] Figure 1 is a schematic diagram of an Intel pin provided in an embodiment of this application;

[0023] Figure 2 is a schematic diagram of a function chain call provided in an embodiment of this application;

[0024] Figure 3 is a schematic diagram of CPU usage monitoring for perf provided in an embodiment of this application;

[0025] Figure 4 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0026] Figure 5 is a flowchart illustrating an operator load acquisition method provided in an embodiment of this application;

[0027] Figure 6 is a schematic diagram of an operator load acquisition device provided in an embodiment of this application;

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

[0029] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0030] In the following description of the embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0031] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0032] The following is a brief introduction to the relevant terms used in the embodiments of this application.

[0033] Instruction-level trace: The set of CPU (central processing unit) instructions during program execution, used to analyze the fine-grained behavior and performance of the program.

[0034] Function-level trace: A collection of function calls during program execution, including function call relationships and coarse-grained information about function execution time. Function traces are used to analyze coarse-grained program behavior and performance.

[0035] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0036] Currently, for internet applications, understanding the performance changes of hotspot / bottleneck functions is crucial for grasping the overall application performance. Hotspot / bottleneck functions can be defined as functions that are frequently called or consume the most resources; their behavior and performance need to be analyzed to meet performance optimization requirements.

[0037] Taking Intel pin as an example, Figure 1 shows a schematic diagram of its structure. Intel pins allow programmers to insert custom code at runtime to monitor and modify program behavior. Intel pins are primarily designed for x86 architecture processors, do not support Arm architecture, and dynamically defining custom code at runtime is time-consuming. Taking Dapper as an example, Dapper is a distributed tracing system. Figure 2 shows a schematic diagram of a function call chain. While Dapper can provide feedback during function calls, it cannot capture fine-grained program behavior (such as memory access behavior). Taking Perf as an example, Perf is a performance analysis tool capable of statistically analyzing various power management unit (PMU) events (such as CPU usage, cache hit rate, branch prediction errors), various kernel events (such as process switching, tick count, slab allocator allocation count), and program function events (function call stack and call time). Figure 3 shows a schematic diagram of Perf's CPU (e.g., CPU0, CPU1, CPU2) usage monitoring. However, Perf is primarily used for collecting and analyzing macro-level performance metrics, rather than tracing specific instruction execution paths.

[0038] In summary, the current tracing methods cannot simultaneously acquire coarse-grained function-level traces and fine-grained instruction-level traces under multiple architectures, resulting in the inability to accurately sample operator loads. Consequently, they fail to meet the requirements for both coarse-grained and fine-grained performance optimization, and thus have limitations in deeply exploring and optimizing application performance.

[0039] In view of this, embodiments of this application provide an operator load acquisition method. This method acquires the target instruction stream during the execution of the target code and determines the CPU instruction set of the target function operator from the target instruction stream, thereby simultaneously acquiring the operator load, which includes both the target instruction stream and the CPU instruction set corresponding to the target function operator. The target instruction stream can represent an instruction-level trace, and the CPU instruction set corresponding to the target function operator can represent a function-level trace. Thus, embodiments of this application are not limited to specific architectures. For multiple different architectures, both coarse-grained function-level traces and fine-grained instruction-level traces under various architectures can be acquired simultaneously. This allows for precise fusion and acquisition of operator load, meeting the requirements for coarse-grained and fine-grained performance optimization of target code under multiple architectures. Furthermore, it enables macroscopic and microscopic performance analysis of the target code, overcoming the limitations in in-depth mining and optimization of application performance.

[0040] In some embodiments, the method provided in this application firstly obtains the target instruction stream of the target code during runtime. The target instruction stream includes an instruction identifier, which represents the virtual address of the next CPU instruction to be executed. Secondly, it obtains the virtual address of the target function operator called during the runtime of the target code. Finally, based on the virtual address of the target function operator and the instruction identifier, it determines the first CPU instruction corresponding to the target function operator from the target instruction stream, and obtains the CPU instruction set corresponding to the target function operator based on the first CPU instruction. The operator payload includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

[0041] In this embodiment, by using the instruction identifier of the target instruction stream and the virtual address of the target function operator, the first CPU instruction corresponding to the target function operator can be accurately determined from the target instruction stream. Starting from this point, the complete set of CPU instructions corresponding to the target function operator can be obtained, achieving both coarse-grained function-level trace and fine-grained instruction-level trace acquisition. This is because, on the one hand, the target instruction stream itself constitutes a fine-grained instruction-level trace, clearly defining the specific instruction execution within the target instruction stream, allowing for in-depth understanding of the micro-execution details within the target code; on the other hand, the set of CPU instructions corresponding to the target function operator constitutes a coarse-grained function-level trace, macroscopically displaying the execution path of the program corresponding to the target code, the call relationships between different functions within the target function operator, and execution time, etc. Thus, this embodiment does not limit the specific architecture; for multiple different architectures, it can simultaneously achieve the acquisition of coarse-grained function-level trace and fine-grained instruction-level trace, fusing the collected operator load to meet the needs of different levels of performance optimization, realizing macro- and micro-level performance analysis of the target code, and breaking through the limitations in in-depth mining and optimization of application performance.

[0042] Furthermore, by performing macro and micro performance analysis on the target code, it is possible to optimize the performance of the operator load, thereby optimizing the scheduling of the system in which the operator load resides, and further exploring the hardware-software co-architecture of the system in which the operator load resides.

[0043] The system architecture of the embodiments of this application will be described exemplarily below.

[0044] As shown in Figure 4, this application provides a computing device.

[0045] The computing device is used to acquire the target instruction stream during the execution of the target code. The target instruction stream includes instruction identifiers, which represent the virtual address of the next CPU instruction to be executed. The computing device is also used to acquire the virtual address of the target function operator called during the execution of the target code. Furthermore, the computing device is used to determine the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator, and to obtain the set of CPU instructions corresponding to the target function operator based on the first CPU instruction.

[0046] The operator load includes the target instruction stream and the set of CPU instructions corresponding to the target function operator.

[0047] Specifically, the computing device includes a processor (e.g., a chip). The processor can obtain the target instruction stream and the virtual address of the target function operator called by the target code during runtime. Then, based on the virtual address and instruction identifier of the target function operator, the processor determines the first CPU instruction corresponding to the target function operator from the target instruction stream, and obtains the set of CPU instructions corresponding to the target function operator based on the first CPU instruction.

[0048] In some embodiments, a virtual machine is deployed on the computing device to run the target code and output the target instruction stream.

[0049] In one implementation, the computing device obtains the target instruction stream during the execution of the target code by instrumenting preset marker instructions before the first line of code and after the last line of code in the target code. These preset marker instructions are used by the virtual machine to identify intervals within the target code. The computing device then uses the virtual machine to execute the target code with the instrumented preset marker instructions, obtaining the target instruction stream output by the virtual machine.

[0050] In one implementation, the computing device obtains the virtual address of the target function operator called by the target code at runtime by: the computing device obtaining the virtual address of the target function operator called by the target code at runtime based on the virtual machine running the target code.

[0051] In other embodiments, the computing device can interact with other computing devices to obtain the target instruction stream and the virtual address of the target function operator called by the target code during runtime from the other computing devices.

[0052] In one implementation, a virtual machine is deployed on another computing device, which runs the target code and outputs the target instruction stream.

[0053] In one implementation, other computing devices instrument pre-marked instructions before the first line of code and after the last line of code in the target code. These other computing devices then run the target code with the instrumented pre-marked instructions using a virtual machine, obtaining the target instruction stream output by the virtual machine. The computing devices also obtain the target instruction stream from the other computing devices during the execution of the target code, as well as the virtual addresses of the target function operators called by the virtual machines on the other computing devices during the execution of the target code.

[0054] Optionally, the preset marker instructions are assembly instructions. In this way, when the preset marker instructions are instrumented before the first line of code and after the last line of code in the target code, the structure and logic are not disrupted, and the normal operation of the original code is not interfered with.

[0055] Optionally, the virtual machine is a virtual machine capable of recognizing assembly instructions. For example, the virtual machine can be modified to recognize assembly instructions. In this way, the virtual machine can recognize preset marked instructions when running the target code, thereby achieving a normal operation mechanism without disrupting the original code.

[0056] In one embodiment, the operator load can be applied to the simulator in the form of an instruction set, and the simulator performs macroscopic and microscopic performance analysis of the target code by simulating and replaying the operator load.

[0057] In other embodiments, the operator workload may also run as slices on a computing device or other computing device. A slice may represent an executable program.

[0058] For example, operator loads can also be run in slices on other computing devices and saved as binary files.

[0059] The aforementioned computing devices may include mobile phones, tablets, handheld computers, personal computers (PCs), cellular phones, personal digital assistants (PDAs), wearable devices (such as smartwatches, smart bracelets, etc.), smart home devices (such as televisions, etc.), in-vehicle systems (such as in-vehicle computers, etc.), smart screens, laptops, desktop computers, or all-in-one computers, etc.

[0060] The aforementioned computing device can also be a server, which can be a single server or a server cluster. The server can be a physical server or a virtualization platform. There can be a single physical server, or two or more physical servers sharing different responsibilities, with each physical server working together to achieve its various functions.

[0061] For example, the server can be a blade server, a high-density server, a rack server, or a tower server, etc.

[0062] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0063] For ease of understanding, the operator load acquisition method provided in this application is described below with reference to the accompanying drawings. This operator load acquisition method is applicable to the computing device shown in Figure 4.

[0064] As shown in Figure 5, this application embodiment provides an operator load acquisition method, which can be executed by the computing device shown in Figure 4. The method includes:

[0065] S501, The computing device acquires the target instruction stream during the execution of the target code.

[0066] The target instruction stream includes an instruction identifier, which represents the virtual address of the next CPU instruction to be executed.

[0067] For example, the instruction identifier can be the instruction PC. The PC value of the instruction PC represents the virtual address of the next CPU instruction to be executed.

[0068] For example, the target code can be code within an application (such as the big data analytics program Spark) that includes hotspot bottleneck functions. In other words, the target code can be code whose behavior and performance need to be analyzed. In this way, the target instruction stream obtained based on the target code can more effectively and accurately locate the hotspot bottleneck functions, as well as each instruction within the target code or the hotspot bottleneck function. This enables analysis of the hotspot bottleneck functions, improving the overall efficiency and performance of the program or system.

[0069] In some embodiments, the computing device obtains the target instruction stream during the execution of target code by: instrumenting preset marker instructions before the first line of code and after the last line of code in the target code, respectively. These preset marker instructions are used by the virtual machine to identify intervals within the target code during execution. The target code with the instrumented preset marker instructions is then executed by the virtual machine to obtain the target instruction stream output by the virtual machine.

[0070] In this embodiment, by inserting pre-marking instructions before and after the target code and running the instrumented target code using a virtual machine, the original code's structure and logic are not disrupted. This allows the virtual machine to accurately define the target code range using pre-marking instructions without interfering with the normal operation of the target code. The virtual machine can then obtain the target instruction stream output when running the target code, reflecting the execution of each CPU instruction and thus accurately reflecting the fine-grained behavior and performance of the target code. Furthermore, since the virtual machine is not limited by a specific architecture, it can run code from various architectures, obtaining target instruction streams from different architectures. This enables the acquisition of operator load data from any GPL-licensed quick emulator (QEMU) architecture (e.g., X86, ARM, AARCH64), allowing for in-depth research and performance evaluation of the target code in diverse programming environments.

[0071] For example, preset marker instructions include a start marker instruction (such as hint9) and an end marker instruction (hint11). The start marker instruction indicates the beginning of the target code, and the end marker instruction indicates the end of the target code. In this way, the start and end marker instructions can define the range of the target code, and the virtual machine can identify the range of the target code when running the target code. Since the virtual machine can recognize assembly language (i.e., assembly instructions), identifying preset marker instructions through the virtual machine does not modify the original target program, is not limited by architecture, and can be applied to more architectures.

[0072] Optionally, the computing device uses instrumentation functions to instrument start marker instructions before the first line of code and end marker instructions after the last line of code in the target code.

[0073] Specifically, the computing device uses instrumentation functions to instrument start and end marker instructions before the first and last lines of code in the target code, respectively. This includes defining an instrumentation function. The instrumentation function is used to instrument preset marker instructions into the target code. The start marker instruction is instrumented before the first line of code in the target code, and the end marker instruction is instrumented after the last line of code in the target code.

[0074] For example, after defining the instrumentation function, the instrumentation function is generated into a dynamic link library file libkperf.so.

[0075] Specifically, when generating the dynamic link library libkperf.so file from the instrumented functions, the header file org_apache_kperfLoader.h and the file kperf_jni.c are also generated. This is because, when generating the dynamic link library libkperf.so file from the instrumented functions, the code corresponding to the instrumented functions is written in a file such as kperf_jni.c, and the corresponding interfaces also need to be defined. This requires the org_apache_kperfLoader.h header file to declare the functions and related content. Therefore, the org_apache_kperfLoader.h header file and the kperf_jni.c file constitute the foundation for the code and interface definitions required to generate libkperf.so.

[0076] For example, the instrumentation function includes a start function and an end function. The start function is used to instrument the start marker instruction before the first line of code in the target code, and the end function is used to instrument the end marker instruction after the last line of code in the target code.

[0077] For example, the start function is as follows:

[0078] For example, the termination function is as follows:

[0079] For example, taking the Spark big data analytics application as an example: First, define the instrumentation functions as described above (a libkperf.so file can be generated after definition). Second, modify the Spark program source code using the instrumentation functions, inserting the start and end functions before and after `task.run(core / src / main / scala / org / apache / spark / executor)` respectively. Then, deploy the Spark cluster within the virtual machine and compile it. Finally, the virtual machine starts and executes the Spark program, outputting the target instruction stream of the Spark program's target code (the main code logic contained in the `task.run` method). Based on this, the computing device obtains the target instruction stream of the target code during runtime.

[0080] Since `task.run` is a call to a method (function), the target code can be represented as the main body of code logic contained in the `task.run` method. The start function and end function are instrumented before and after `task.run(core / src / main / scala / org / apache / spark / executor)`, respectively. In other words, the start function and end function are instrumented before the first line of code and after the last line of code in the main body of code logic contained in the `task.run` method.

[0081] Deploying a Spark cluster within a virtual machine allows the virtual machine to provide an independent running environment, flexibly allocating resources such as CPU, memory, and disk to the Spark cluster as needed. This facilitates the simulation of production environment scenarios of different scales and configurations, avoids resource contention with other applications on the host machine, and makes the Spark cluster run more stably.

[0082] In the embodiments of this application, an exemplary implementation method is provided for a computing device to obtain the target instruction stream of the target code in the Spark big data analysis program during runtime. When the virtual machine starts and executes the Spark program, through the previous instrumentation operation, the modified virtual machine that can recognize assembly instructions can accurately define the target code range and output the target instruction stream of the target code, thereby accurately reflecting the fine-grained behavior and performance of the target code (the code logic body contained in the task.run method).

[0083] S502, The computing device obtains the virtual address of the target function operator called at runtime by the target code.

[0084] In some embodiments, the computing device obtains the virtual address of the target function operator called at runtime by the target code, including: obtaining the starting virtual address of the target library from the target memory-mapped file; obtaining the offset of the function operator in the target library from the .so file; and determining the virtual address of the function operator in the target library based on the starting virtual address of the target library and the offset of the function operator in the target library.

[0085] The target memory-mapped file records memory mapping information when the virtual machine runs the target code. The target library represents the libraries called by the target code at runtime, and includes target function operators.

[0086] In one implementation, the target memory-mapped file can be the / proc / pid / maps file. The / proc / pid / maps file records memory-mapped information when the virtual machine runs the target code.

[0087] In one implementation, the .so file can be a shared library file (lib.so) stored on the hard drive of the computing device where the virtual machine is deployed. Specifically, the .so file can be an executable file (i.e., the file corresponding to the object code) and / or a third-party shared library file. For example, in the runtime environment of a Spark program, there may be a third-party shared library file (libmath.so) used for mathematical calculations, and an executable file (libspark_core.so) closely related to Spark's own functionality.

[0088] In one implementation, the .so file stored on the hard drive of the computing device deployed by the virtual machine has a starting physical address, and the function operators inside the .so file also have starting physical addresses. In this way, using the starting physical addresses of the .so file and the starting physical addresses of the function operators inside the .so file makes it easier to calculate the offsets of function operators in the target library later.

[0089] In one implementation, when the target code is executed, some or all of the .so files (such as lib.so) are called. The called .so file is the target library, which can exist in the process running the target code as a lib code segment or data segment, and the contents of the target library are mapped to the process's virtual memory space. The process's / proc / pid / maps file records the starting virtual address of the target library.

[0090] In this embodiment, when the target code is executed, the called lib.so file is named the target library. Associating the so file with the target library establishes an effective mapping between the code and data structures at the physical storage level and the virtual memory space during process execution. The starting virtual address of the target library, recorded in the process's / proc / pid / maps file, allows for precise tracking of the target library's location in virtual memory.

[0091] For example, obtaining the offset of a function operator in a target library from a .so file includes: determining the starting physical address of the .so file; identifying the function operator in the target library from the .so file and obtaining its starting physical address; calculating the difference between the starting physical address of the .so file and the starting physical address of the function operator in the target library; and using this difference as the offset of the function operator in the target library.

[0092] In this embodiment of the application, since the target library includes target function operators and the target library is an SO file called by the process running the target code, by obtaining the offset of the function operator in the target library from the SO file, the relative position of the function operator in the SO file can be accurately located during the runtime of the target code, and the runtime behavior of the function operator can be accurately tracked.

[0093] In one implementation, determining the virtual address of a function operator in the target library based on the starting virtual address of the target library and the offset of the function operator in the target library includes: using the sum of the starting virtual address of the target library and the offset of the function operator in the target library as the virtual address of the function operator in the target library.

[0094] In this embodiment, since the relative position of the function operator in the target library remains unchanged regardless of whether it is in physical space or virtual space, the virtual address of the function operator is determined by the sum of the starting virtual address of the target library and the offset of the function operator. This allows the virtual address of the target function operator to be located quickly and accurately in the virtual memory space during the execution of the target code.

[0095] In some embodiments, the objective function operator can be one or more.

[0096] In one implementation, if there are multiple objective function operators, the virtual address of each objective function operator is determined.

[0097] S503, the computing device determines the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator, and obtains the set of CPU instructions corresponding to the target function operator based on the first CPU instruction.

[0098] The operator load includes the target instruction stream and the set of CPU instructions corresponding to the target function operator.

[0099] In some embodiments, the computing device determines the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator. This includes: determining a target instruction identifier in the target instruction stream that has the same starting virtual address as the target function operator; and determining the CPU instruction corresponding to the target instruction identifier as the first CPU instruction corresponding to the target function operator.

[0100] In this embodiment, by matching the starting virtual address of the target function operator with the instruction identifier in the target instruction stream, the first CPU instruction corresponding to the target function operator can be accurately traced from the target instruction stream. This enables precise location of the start instruction of each target function operator, breaks down the barrier between instruction-level trace and function-level trace, and aligns the target function operator at the beginning of the target instruction stream (i.e., the position of the first CPU instruction), thereby achieving precise location and analysis of the target function operator.

[0101] In some embodiments, obtaining the CPU instruction set corresponding to the target function operator based on the first CPU instruction includes: tracing function jump instructions and function return instructions in the target instruction stream based on the first CPU instruction; pairing the function jump instructions and function return instructions; and using the CPU instructions between the first CPU instruction and the unpaired function return instructions as the CPU instruction set corresponding to the target function operator.

[0102] Among them, the function jump instruction is used to indicate a jump to the function to be called, and the function return instruction is used to indicate the end of the called function.

[0103] In this embodiment, by tracing and pairing function jump instructions and function return instructions in the target instruction stream based on the first CPU instruction, the sub-function operators called by the target function operator can be traced. For example, every two successfully paired function jump instructions and function return instructions are identified as a sub-function operator. During the tracing of sub-function operators, the sub-function call stack (including sub-function call relationships) can be clearly identified. Based on this, unpaired function return instructions are identified as the end of the target function operator. In this way, the barrier between instruction-level trace and function-level trace is broken down, aligning the function at the end of the instruction stream (i.e., unpaired function return instructions). This allows for precise acquisition of the CPU instruction set corresponding to the target function operator, obtaining a coarse-grained function-level trace from a macroscopic scale, thereby enabling in-depth analysis of the internal logic flow of the target function operator during execution, and ultimately, accurate evaluation of its behavior and performance.

[0104] In one implementation, pairing function jump instructions and function return instructions involves using brackets to pair them. This ensures accurate pairing of function jump instructions and function return instructions.

[0105] In some embodiments, if there are multiple target function operators, the computing device determines the first CPU instruction corresponding to each target function operator from the target instruction stream based on the virtual address and instruction identifier of each target function operator, and obtains the CPU instruction set corresponding to each target function operator based on each first CPU instruction.

[0106] In other embodiments, if there are multiple target function operators, the operator payload includes the target instruction stream and the set of CPU instructions corresponding to each target function operator.

[0107] In other embodiments, the operator payload also includes a snapshot of the system registers corresponding to the target code.

[0108] As shown in Figure 5, in one implementation, the method further includes: S504, the computing device obtains a snapshot of the system registers corresponding to the target code.

[0109] The system register snapshot corresponding to the target code is used to represent the system state at the moment the target code starts running.

[0110] In this embodiment of the application, by obtaining a system snapshot representing the start time of the target code, it is possible to quickly jump to the runtime system state, thereby enabling accurate reproduction of the initial environment of the target code runtime when needed (e.g., in the application scenario of simulation and replay of operator load by a simulator), thereby enabling in-depth analysis of problems in the target code runtime process, performance optimization (e.g., performance tuning of operator load, scheduling optimization of the system where the load is located), verification of system behavior, and exploration of the system's hardware and software co-architecture, etc.

[0111] In other embodiments, the number of operator loads can be one or more.

[0112] In one implementation, if there are multiple operator loads, the method collects an operator load set. This set includes multiple operator loads. This expands the application scenarios of the solution, enabling it to be adapted to operator load collection at more scales, rather than being limited to a single operator load, and achieving efficient operator load collection for real-world business scenarios.

[0113] As shown in Figure 6, this embodiment of the application provides an operator load acquisition device 200, which includes a first acquisition module 21, a second acquisition module 22, and a third acquisition module 23. The first acquisition module 21 acquires the target instruction stream during the execution of the target code. The target instruction stream includes an instruction identifier, which represents the virtual address of the next CPU instruction to be executed. The second acquisition module 22 acquires the virtual address of the target function operator called during the execution of the target code. The third acquisition module 23 determines the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address and instruction identifier of the target function operator, and obtains the CPU instruction set corresponding to the target function operator based on the first CPU instruction. The operator load includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

[0114] As shown in Figure 7, this embodiment of the application provides a computing device 500. The computing device 500 includes a processor 510 and a memory 520 for storing processor-executable instructions. When the processor 510 is configured to execute instructions, the computing device 500 implements the operator load acquisition method described above.

[0115] The computing device 500 shown in Figure 7 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0116] The computing device 500 is manifested in the form of a general-purpose computing device. The components of the computing device 500 may include, but are not limited to: one or more processors 510, memory 520, communication bus 540 connecting different system components (including memory 520 and processor 510), and communication interface 530.

[0117] The communication bus 540 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0118] Computing device 500 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device, including volatile and non-volatile media, removable and non-removable media.

[0119] Memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The computing device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Although not shown in FIG7, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disc drive for reading and writing to a removable non-volatile optical disc (e.g., a compact disc read-only memory (CD-ROM), a digital video disc read-only memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to the communication bus 540 via one or more data media interfaces. Memory 520 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0120] A program / utility having a set (at least one) of program modules can be stored in memory 520. Such program modules include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The program modules typically perform the functions and / or methods described in the embodiments of this application.

[0121] The computing device 500 can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), one or more devices that enable a user to interact with the computing device, and / or any device that enables the computing device to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through the communication interface 530. Furthermore, the computing device 500 can also communicate with one or more networks (e.g., Local Area Network (LAN), Wide Area Network (WAN), and / or public networks, such as the Internet) via a network adapter (not shown in Figure 7). This network adapter can communicate with other modules of the computing device via the communication bus 540. It should be understood that, although not shown in Figure 7, other hardware and / or software modules can be used in conjunction with the computing device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Arrays of Independent Drives (RAID) systems, tape drives, and data backup storage systems.

[0122] The processor 510 executes various functional applications and data processing by running programs stored in the memory 520.

[0123] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the computing device 500. In other embodiments of this application, the computing device 500 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0124] It is understood that the aforementioned computing devices, etc., include hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the exemplary units and algorithm steps described in conjunction with the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0125] This application embodiment can divide the above-mentioned computing device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0126] This application embodiment also provides a storage medium storing computer program instructions, which, when executed by a computing device, enable the computing device to implement the operator load acquisition method described above.

[0127] This application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to execute the operator load acquisition method provided in this application.

[0128] The computing device, storage medium, or computer program product provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0129] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0130] In the embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0131] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for acquiring operator load, characterized in that, include: Obtain the target instruction stream during the execution of the target code, wherein the target instruction stream includes an instruction identifier, and the instruction identifier represents the virtual address of the next CPU instruction to be executed; Obtain the virtual address of the target function operator called during the runtime of the target code; Based on the virtual address of the target function operator and the instruction identifier, the first CPU instruction corresponding to the target function operator is determined from the target instruction stream, and the CPU instruction set corresponding to the target function operator is obtained based on the first CPU instruction; the operator load includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

2. The method according to claim 1, characterized in that, The step of determining the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address of the target function operator and the instruction identifier includes: Identify the target instruction identifier in the target instruction stream that has the same starting virtual address as the target function operator; The CPU instruction corresponding to the target instruction identifier is determined as the first CPU instruction corresponding to the target function operator.

3. The method according to claim 1 or 2, characterized in that, The step of obtaining the CPU instruction set corresponding to the target function operator according to the first CPU instruction includes: Based on the first CPU instruction, the function jump instruction and function return instruction in the target instruction stream are traced. The function jump instruction is used to indicate a jump to the function to be called, and the function return instruction is used to indicate the end of the called function. The function jump instruction and the function return instruction are paired; The CPU instructions between the first CPU instruction and the unpaired function return instruction are taken as the set of CPU instructions corresponding to the target function operator.

4. The method according to any one of claims 1-3, characterized in that, Obtaining the virtual address of the target function operator called at runtime of the target code includes: The starting virtual address of the target library is obtained from the target memory mapping file, which is used to record memory mapping information when the virtual machine runs the target code, and the target library is used to represent the library called by the target code during runtime; the target library includes the target function operator; Obtain the offsets of function operators in the target library from the .so file; The virtual address of the function operator in the target library is determined based on the starting virtual address of the target library and the offset of the function operator in the target library.

5. The method according to claim 4, characterized in that, Determining the virtual address of the function operator in the target library based on the starting virtual address of the target library and the offset of the function operator in the target library includes: The sum of the starting virtual address of the target library and the offset of the function operator in the target library is used as the virtual address of the function operator in the target library.

6. The method according to any one of claims 1-5, characterized in that, Obtain the target instruction stream during the execution of the target code, including: Preset marker instructions are inserted before the first line of code and after the last line of code in the target code. The preset marker instructions are used by the virtual machine to identify the intervals of the target code when the target code is run. The target code of the preset marked instruction is instrumented by running a virtual machine to obtain the target instruction stream output by the virtual machine.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Obtain a snapshot of the system registers corresponding to the target code. The snapshot of the system registers corresponding to the target code is used to represent the system state at the moment when the target code starts running.

8. An operator load acquisition device, characterized in that, include: The first acquisition module is used to acquire the target instruction stream when the target code is running. The target instruction stream includes an instruction identifier, which represents the virtual address of the next CPU instruction to be executed. The second acquisition module is used to acquire the virtual address of the target function operator called by the target code during runtime; The third acquisition module is used to determine the first CPU instruction corresponding to the target function operator from the target instruction stream based on the virtual address of the target function operator and the instruction identifier, and to obtain the CPU instruction set corresponding to the target function operator based on the first CPU instruction; the operator load includes the target instruction stream and the CPU instruction set corresponding to the target function operator.

9. A computing device, characterized in that, include: A processor, and a memory for storing processor-executable instructions; When the processor is configured to execute the instructions, the computing device implements the operator load acquisition method as described in any one of claims 1-7.

10. A storage medium storing computer program instructions thereon; characterized in that, When the computer program instructions are executed by the computing device, the computing device implements the operator load acquisition method as described in any one of claims 1-7.

11. A program product, characterized in that, The method includes a computer-readable storage medium storing a computer program, which, when executed by at least one processor, causes the at least one processor to perform the operator load acquisition method according to any one of claims 1-7.

Images