Compilation methods, compilation devices, equipment, and storage media
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-19
- Publication Date
- 2026-08-14
AI Technical Summary
但实际应用中，有时判断是否需要内联对应的耗时较长，直接影响了程序本身的运行效率
[0013]本申请实施例提供的编译处理方法、编译处理装置、设备及存储介质中，对目标程序执行预加载处理，包括：基于目标程序中的函数的字节码信息，确定热点函数，生成热点函数表，在目标程序的运行过程中，若检测到当前待运行的目标函数在热点数据表中，将目标函数进行内联。本方案中，程序运行前通过预加载处理获取了热点函数表，程序运行中只需检测目标函数是否在热点函数表中，而不需要对目标函数是否需要执行内联操作做判断，这样可以节省判断过程所需的时间，因而能够加快函数的响应速度，从而能够提高程序本身运行的效率。
Smart Images
Figure CN122570071A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of compilation technology, and in particular to a compilation processing method, compilation processing apparatus, device and storage medium. Background Technology
[0002] A virtual machine (VM) is a hardware operating environment simulated on a physical computer. It has its own virtual resources (such as processor, memory, storage, etc.) and can compile high-level languages into machine code through a compiler, enabling multiple operating systems to run simultaneously on the same physical machine.
[0003] In related technologies, some compilers, such as Just-In-Time (JIT) compilers, often determine during program execution whether functions to be executed need to be optimized by inlining. If so, they perform the inlining. However, in practical applications, determining whether inlining is necessary can be time-consuming, directly impacting the program's execution efficiency. Summary of the Invention
[0004] This application provides a compilation processing method, compilation processing apparatus, device, and storage medium to improve the response speed of functions.
[0005] Firstly, this application provides a compilation processing method, which includes: performing preloading processing on a target program; the preloading processing includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table; hot functions are functions in the target program whose call frequency, execution time, and / or performance impact meet preset conditions; during the execution of the target program, the target functions to be executed are detected in the hot function table in real time; if a target function is detected to exist in the hot function table, the target function is inlined to enable the target program to be compiled quickly.
[0006] In some embodiments, the method further includes: determining the hotspot function corresponding to the target function according to the hotspot function table, and obtaining the bytecode of the hotspot function; compiling the bytecode of the hotspot function to generate an intermediate representation of the hotspot function; wherein the intermediate representation is an internal data structure used to describe the control flow and operation semantics of the hotspot function; then, inlining the target function includes: inlining the target function based on the intermediate representation of the hotspot function.
[0007] In some embodiments, generating an intermediate representation of hotspot functions includes: compiling the bytecode of at least a portion of the hotspot functions in the hotspot function table before running the target program to generate an intermediate representation of at least a portion of the hotspot functions; wherein, the at least a portion of the hotspot functions includes hotspot functions corresponding to the target function.
[0008] In some embodiments, generating intermediate representations of hotspot functions includes: during the execution of the target program, compiling the bytecode of the hotspot functions in the target program according to the calling order of the hotspot functions in the hotspot function table through a compilation thread different from the thread running the target program, and generating the corresponding intermediate representations.
[0009] In some embodiments, the intermediate representation includes an IR syntax tree; compiling the bytecode of the hotspot function to generate an intermediate representation of the hotspot function includes: converting the bytecode of the hotspot function into an IR syntax tree and caching the IR syntax tree; inlining the target function based on the intermediate representation of the hotspot function includes: during the just-in-time compilation of the target function, copying the cached IR syntax tree and inlining the copied IR syntax tree to the call location corresponding to the target function, so as to embed the IR syntax tree of the hotspot function into the compilation structure corresponding to the target function.
[0010] In some embodiments, determining hot functions in the target program based on the bytecode information of functions in the target program includes: if the bytecode information of a function satisfies a first condition, the function is identified as a hot function; the first condition includes at least one of the following: the size of the function's bytecode is not less than a first threshold; the size of the function's bytecode's operation stack space is not less than a second threshold; the sequence of the function's bytecode contains branch jump bytecode; the function's bytecode contains function call bytecode.
[0011] In some embodiments, the method further includes: after the target program has been run a first number of times, obtaining the running information of candidate functions in the target program that are not stored in the hotspot function table; detecting whether the candidate functions meet the second condition based on the running information; and if they meet the condition, adding the candidate functions to the hotspot function table.
[0012] Secondly, this application provides a compilation processing apparatus, comprising: a preloading module for performing preloading processing on a target program; the preloading processing includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table; hot functions are functions in the target program whose call frequency, execution time, and / or performance impact meet preset conditions; a detection module for real-time detection of the target functions to be executed in the hot function table during the execution of the target program; and an inlining module for inlining the target functions if they are detected to exist in the hot function table, so that the target program can be compiled quickly.
[0013] The compilation processing method, apparatus, device, and storage medium provided in this application embodiment perform preloading processing on the target program, including: determining hot functions based on the bytecode information of functions in the target program, generating a hot function table, and inlining the target function if it is detected that the target function to be executed is in the hot function table during the execution of the target program. In this solution, the hot function table is obtained through preloading processing before the program runs. During program execution, it is only necessary to check whether the target function is in the hot function table, without needing to determine whether the target function needs to be inlined. This saves the time required for the determination process, thereby speeding up the function response and improving the efficiency of the program itself. Attached Figure Description
[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0015] Figure 1 A flowchart illustrating a compilation process method provided in this application embodiment;
[0016] Figure 2 A flowchart illustrating another compilation process method provided in this application embodiment;
[0017] Figure 3 A flowchart illustrating yet another compilation processing method provided in this application embodiment;
[0018] Figure 4 This is a schematic diagram of the structure of a compilation processing apparatus provided in an embodiment of this application;
[0019] Figure 5 This is a schematic diagram of another compilation processing apparatus provided in an embodiment of this application;
[0020] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.
[0022] A virtual machine (VM) can be understood as a hardware operating environment simulated on a physical computer. It has its own virtual resources (such as processor, memory, and storage) and runs independently. VMs abstract and isolate the host machine's hardware resources, enabling multiple VMs and multiple operating systems to run simultaneously on the same physical machine.
[0023] A virtual machine can run various applications. A function within an application is a reusable block of code, and the CPU executes the code within these functions sequentially. When the CPU executes the code of the calling function, if it reaches the called function, the calling function pauses, and the CPU switches to executing the called function's code. After the called function finishes executing, the CPU returns to the calling function, which then continues execution based on its previous state. The execution process of a program can be considered as a process of mutual calls between multiple functions.
[0024] However, function calls incur time and space overhead. For example, before executing a function, the program must push the actual arguments, local variables, return address, and several registers onto the operand stack corresponding to the function's bytecode. Only then can the code in the function body be executed from the operand stack. After the code in the function body finishes executing, the context must be cleaned up, and all data previously pushed onto the operand stack must be popped off the stack before execution can continue from the point of the function call. Stack space refers to the memory space where the data within a function is stored. In the operating system, the operand stack space is finite. Frequent and excessive use of stack space can cause program errors due to insufficient stack space. The ultimate result of an infinite loop of recursive function calls is that the operand stack space in memory eventually becomes exhausted.
[0025] To eliminate the time and space overhead of function calls, C++ provides a method to improve efficiency: replacing function calls with function bodies at compile time. Functions with function bodies directly embedded at function call locations are called inline functions. In other words, at the compiler level, the machine code generated for inline functions is no longer the machine code for the function call itself, but rather the function to be executed is directly appended to the location of the current function call for internal association. This avoids repeated jumps during code execution, thereby reducing the overhead of function calls and improving code execution efficiency.
[0026] However, if the function's execution time is very short, and the function's call time is less than its execution time, then function inlining is meaningless. Therefore, it is often necessary to determine whether inlining is necessary. In related technologies, some compilers, such as JIT compilers, will compile the function during runtime if they determine that the function to be executed needs to be inlined, and then copy the compiled function body to the execution point to complete the inlining optimization.
[0027] To address the aforementioned technical problems, this application provides the following technical concept: Before program execution, the program undergoes preloading to identify hot-spot functions and generate a hot-spot function table. During program execution, it is only necessary to check whether the target function is in the hot-spot function table, without needing to determine whether the target function is inlined. This saves time and thus speeds up function response, thereby improving program execution efficiency.
[0028] Example 1
[0029] Figure 1 This is a flowchart illustrating a compilation processing method provided in an embodiment of this application. The execution entity of this method can be a virtual machine or a server running a virtual machine, or a compilation processing device. The compilation processing device can be implemented in hardware, software, or a combination of both. For ease of description, the following explanation uses a virtual machine as the execution entity as an example. Figure 1 As shown, the method may include:
[0030] S101. Perform preloading processing on the target program.
[0031] The preloading process includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table. The hot functions in the hot function table are functions in the target program whose call frequency, execution time, and / or performance impact meet preset conditions.
[0032] In this embodiment, the target program can be an executable file in bytecode form. The target program may include multiple functions, each with corresponding function information and bytecode information. Function information may include function name, function identifier, function signature, module to which the function belongs, class to which the function belongs, bytecode address, and / or bytecode offset. Bytecode information may include bytecode size, the size of the corresponding stack space, bytecode sequence, instruction types in the bytecode, number of branch jump bytecode, and number of function call bytecode, etc.
[0033] During preloading, the virtual machine can read and parse the configuration file corresponding to the preloading process. The configuration file may include rules for determining hot functions, bytecode statistics, runtime statistics, and the storage rules for the hot function table. For example, the configuration file may include thresholds for bytecode size, operation stack space size, branch jump bytecode count, function call bytecode count, call frequency, execution time, performance impact, and / or the hot function table update cycle.
[0034] In one possible implementation, the configuration file may include both precise configuration mode and broad configuration mode.
[0035] In precise configuration mode, the configuration file can directly record the function name, function signature, function identifier, or bytecode address of functions designated as hot functions. The virtual machine uses this information to identify the corresponding hot functions in the target program. For example, if the configuration file directly records the unique identifier of function F1 as ModuleA.ClassA.F1(int), then when scanning the target program, the virtual machine can locate function F1 in the target program based on ModuleA.ClassA.F1(int) and identify it as a hot function.
[0036] In broad configuration mode, bytecode characteristic conditions and / or runtime statistics can be recorded in the configuration file. The virtual machine matches the target program based on the bytecode characteristic conditions and / or runtime statistics to automatically identify hot functions in the target program.
[0037] During preloading, the virtual machine can read and parse the configuration file using a designated configuration parsing thread or a dedicated compilation thread, and store the parsed configuration information in a configuration object in the virtual machine's runtime memory. The configuration object can include a set of function names, a set of function signatures, a set of bytecode feature thresholds, a set of runtime statistics thresholds, and hotspot function table update parameters from the configuration information. The virtual machine can then scan and analyze the bytecode information of functions in the target program based on the configuration object.
[0038] In this embodiment, analyzing functions in the target program can be understood as performing a global analysis of the target program. "Global" in this embodiment means using the entire target program as the scope of analysis, rather than analyzing only currently executed functions or only the target functions to be executed. For example, when the target program includes a main program module and bytecode modules required for its execution, the virtual machine can perform a unified traversal and statistical analysis of the functions in these modules. In this way, a hotspot function table covering the entire target program can be obtained before or in the early stages of its execution, reducing the possibility of missing subsequent high-frequency functions by relying solely on currently executed functions.
[0039] During bytecode analysis, the virtual machine can traverse the function metadata in the target program. For each function, the virtual machine can obtain the bytecode start address, bytecode length, maximum stack space, function name, function signature, and module to which the function belongs based on the function metadata. Subsequently, the virtual machine can parse the bytecode sequence of the function and count the number of instructions corresponding to each instruction type in the bytecode sequence. For example, the virtual machine can count the number of branch jump bytecode instructions, function call bytecode instructions, return bytecode instructions, and / or exception handling related bytecode instructions, and determine the bytecode complexity, control flow complexity, and / or call relationship complexity of the function based on the number of instructions corresponding to each instruction type. If the above complexity meets a preset complexity condition, the function is identified as a hot function or a candidate hot function. In some examples, if the bytecode information of a function meets a first condition, the function can be designated as a hot function. The first condition includes at least one of the following:
[0040] The bytecode size of the function is not less than a first threshold; the operand stack space size corresponding to the function's bytecode is not less than a second threshold; the function's bytecode sequence contains branch jump bytecode; and the function's bytecode contains function call bytecode. The first and second thresholds can be set according to the target program type, virtual machine runtime environment, processor architecture, and application performance requirements.
[0041] In other examples, the virtual machine can also identify hot functions by combining function runtime statistics. Runtime statistics can include the number of function calls, call frequency, cumulative execution time, average execution time, maximum execution time, and / or performance impact.
[0042] To record the number of function calls, the virtual machine can set a call counter at the function entry point. Each time the target program reaches that function, the virtual machine increments the call counter, directly obtaining the function call count. To record the execution time of a function, the virtual machine can record the start time at the function entry point and the end time at the function return point. The difference between the end time and the start time determines the execution time of that function, and the execution time yields runtime statistics such as call frequency, cumulative execution time, average execution time, and maximum execution time. The virtual machine can record the call count, cumulative execution time, and average execution time in a function execution statistics table. The function execution statistics table can be set up separately from the hot function table, or it can be used as a statistical field in the hot function table.
[0043] The performance impact can be determined based on the number of function calls and the function execution time. For example, the performance impact can be the product of the number of function calls and the average execution time of the function. Alternatively, the performance impact can also be determined by a weighted average of call frequency, cumulative execution time, and bytecode complexity; this application does not limit this approach. When the function's call frequency, execution time, and / or performance impact meet preset conditions, the virtual machine can identify the function as a hot function.
[0044] For example, within a statistical period of the target program P, the virtual machine records that function F1 is called 5000 times with an average execution time of 50 microseconds; function F3 is called 1500 times with an average execution time of 80 microseconds. If, in this embodiment, the performance impact is set as the product of the number of calls and the average execution time, reading the call count and average execution time of F1 and F3 respectively, we find that the performance impact of F1 is 250 milliseconds, and the performance impact of F3 is 120 milliseconds. If the performance impact threshold is set to 200 milliseconds in the configuration file, then F1 can be identified as a hotspot function. If the call count threshold is set to 1000 times in the configuration file, then function F3, whose call count exceeds the threshold, can be identified as a hotspot function.
[0045] After identifying hot functions, the virtual machine can store their function information in a hot function table. The hot function table can be implemented using data structures such as hash tables, arrays, linked lists, tree structures, or database tables. In this embodiment, to improve query efficiency, a hash table can be used to implement the hot function table.
[0046] When the hot function table is implemented using a hash table, the keys in the hot function table can be the function name, function signature, function identifier, bytecode address, or a unique function identifier formed by combining the module identifier, class name, function name, and function signature. The values in the hot function table can be hot function records.
[0047] For example, a hot function table can store hot function records for functions F1, F2, and F3. Each hot function record can include a unique function identifier, bytecode address, bytecode characteristic information, runtime statistics, and intermediate representation status. The bytecode characteristic information can include bytecode size, operand stack size, number of branch jump bytecodes, and / or number of function call bytecodes; the runtime statistics can include the number of calls, average execution time, and / or performance impact; the intermediate representation status indicates whether the hot function has generated a corresponding intermediate representation, specifically including uncompiled, compiling, intermediate representation generated, and invalidated states.
[0048] For example, the unique identifier of function F1 can be ModuleA.ClassA.F1(int), and its bytecode address can be 0x1000. The intermediate representation status can be represented by a status field, which can be an enumeration value, an integer value, or a string value. For example, a status field value of 0 indicates an uncompiled state, a value of 1 indicates a compiling state, a value of 2 indicates an intermediate representation has been generated, and a value of 3 indicates an invalid state. When F1 has not yet generated an intermediate representation, the status field value corresponding to F1 can be 0 to indicate that the intermediate representation status of F1 is uncompiled. The unique identifier of function F2 can be ModuleA.ClassB.F2(), and its bytecode address can be 0x1200. When F2 has not yet generated an intermediate representation, the status field value corresponding to F2 is 0 to indicate that the intermediate representation status can be uncompiled. Subsequently, when the virtual machine detects that the target function to be run is F1, it can query the hot function table based on the unique identifier of F1 and obtain the hot function record corresponding to F1.
[0049] A hot function table can be stored in the virtual machine's runtime memory for quick lookup during target program execution. To support continued use in subsequent runs, the hot function table can also be persistently stored in a local file, database, or configuration file when the target program exits. For example, the virtual machine can write the function names, function signatures, call counts, average execution time, and performance impact from the hot function table to a hot function configuration file when the target program exits. The next time the target program runs, the virtual machine can read this hot function configuration file and restore the hot function table.
[0050] The hotspot function table can be updated using methods such as scheduled updates, counted updates, or updates upon program exit. Scheduled updates mean the virtual machine updates the hotspot function table at preset time intervals, such as every 10 seconds. Counted updates mean the hotspot function table is updated during the target program's execution when the number of function calls reaches a preset number, such as every 1000 new function calls. Updates upon program exit mean that when the target program terminates, the virtual machine updates the hotspot function table based on the function execution statistics collected during the current execution and outputs a hotspot function configuration file.
[0051] S102. During the execution of the target program, the target functions to be executed are detected in the hot function table in real time.
[0052] In this embodiment, after the target program starts running, the virtual machine can determine the target function to be executed. The target function to be executed can be the function that the target program is about to execute, or it can be the function being analyzed during just-in-time compilation.
[0053] The virtual machine can query the hotspot function table based on the target function's function name, function signature, function identifier, or bytecode address. If the hotspot function table is implemented using a hash table, the virtual machine can perform a real-time hash query using the target function's unique identifier as the key. If a corresponding hotspot function record is found, it means the target function exists in the hotspot function table and needs to be inlined subsequently. If no corresponding hotspot function record is found, it is determined that the target function does not exist in the hotspot function table. If the target function does not exist in the hotspot function table, the virtual machine can process the target function according to the regular just-in-time (JIT) compilation process. This process includes: real-time judgment of whether the target function meets the inlining conditions, and inlining the target function if the conditions are met, or executing the target function as a normal function call if the conditions are not met.
[0054] It should be noted that the hotspot functions in the target program and the hotspot functions corresponding to the target function belong to the same category of functions, but they are processed at different stages. The hotspot functions in the target program refer to the set of hotspot functions pre-determined from multiple functions in the target program during the pre-loading process, after analyzing the bytecode information and / or runtime statistics of the functions. The function information in this set is stored in a hotspot function table. The hotspot function corresponding to the target function refers to the specific hotspot function identified in the hotspot function table that has a corresponding relationship with the target function after the target function to be executed is detected during the execution of the target program. This correspondence can be determined through function name, function identifier, function signature, bytecode address, and / or bytecode offset.
[0055] For example, during the execution of target program P, if the virtual machine determines that the target function to be executed is F1, it can query the hot function table using ModuleA.ClassA.F1(int) as the key. Since a hot function record corresponding to F1 exists in the hot function table, it can be determined that F1 exists in the hot function table. If the target function to be executed is F4, and a hot function record corresponding to F4 does not exist in the hot function table, the virtual machine can execute F4 according to the normal just-in-time compilation process.
[0056] S103. If the target function is detected to exist in the hot function table, the target function will be inlined to enable the target program to be compiled quickly.
[0057] In this embodiment, if the objective function exists in the hot function table, the virtual machine can inline the objective function. Specifically, for example... Figure 2 As shown, this method may further include: S104, the virtual machine can determine the hotspot function corresponding to the target function according to the hotspot function table, and obtain the bytecode of the hotspot function. S105, the virtual machine can compile the bytecode of the hotspot function to generate an intermediate representation of the hotspot function. Correspondingly, S103 may include: inlining the target function based on the intermediate representation of the hotspot function. The intermediate representation can be an internal data structure used to describe the control flow and operational semantics of the hotspot function.
[0058] Furthermore, the intermediate representation can include an Indirect Reference Script (IR) syntax tree. The virtual machine can convert the bytecode of hot functions into an IR syntax tree and cache it. When the target function is compiled just-in-time (JIT), the virtual machine can copy the cached IR syntax tree and inline the copied IR syntax tree to the corresponding call location of the target function. Therefore, the virtual machine does not need to repeatedly read the bytecode of hot functions during the runtime of the target function, nor does it need to repeatedly convert the bytecode of hot functions into an IR syntax tree.
[0059] For example, during the execution of target program P, if the virtual machine detects that the target function to be executed is F1, and F1 exists in the hot function table, the virtual machine can read the bytecode corresponding to bytecode address 0x1000 of F1 and convert the bytecode of the hot function F1 into an IR syntax tree. After the conversion, the virtual machine can write the IR syntax tree cache address into the hot function record corresponding to F1 and update the intermediate representation state of F1 to the generated intermediate representation state. When the target program runs to the location where F1 is called, the virtual machine copies the cached IR syntax tree corresponding to F1 and inlines it to the location where the target function is called by attaching the root node of the copied IR syntax tree to the IR node corresponding to the target function call location.
[0060] In one implementation, the compilation of the bytecode of hotspot functions and the generation of intermediate representations of these functions can be completed before the target program runs. That is, the virtual machine can compile the bytecode of at least a portion of the hotspot functions in the hotspot function table before the target program runs, generating intermediate representations of these at least a portion of the hotspot functions. These at least a portion of the hotspot functions include the hotspot functions corresponding to the target function. Thus, during the execution of the target program, if the target function to be executed exists in the hotspot function table, the virtual machine can directly perform inlining based on the already generated intermediate representations.
[0061] For example, before the target program P runs, the virtual machine can first compile F1 and F3 in the hot function table, generating the IR syntax tree for F1 and the IR syntax tree for F3 respectively. When the target program P runs to F1 or F3, it can directly copy the cached IR syntax tree and inline the copied syntax tree, without needing to reread the bytecode of F1 or F3 at runtime, thus saving time in determining whether inlining is necessary.
[0062] Specifically, the IR syntax tree can include multiple nodes describing function input parameters, local variables, operation instructions, control flow, function call instructions, and return instructions. When the target program P runs to the location in the target function that calls the hot function, the virtual machine can use the call node originally used to call the hot function as the inline insertion location; after copying the IR syntax tree corresponding to the hot function, it replaces the formal parameter nodes in the copied IR syntax tree according to the actual parameter information at the call node, and adjusts the local variable nodes, return nodes, and control flow nodes in the copied IR syntax tree according to the context information of the target function; then, it embeds the adjusted IR syntax tree nodes into the call node location of the target function, so that the function logic corresponding to the hot function replaces the original function call logic in the target function, thereby optimizing the corresponding execution efficiency of the compiler.
[0063] After inlining, the call nodes that originally pointed to the hot function in the IR syntax tree corresponding to the target function are replaced by the IR syntax tree nodes corresponding to the hot function, forming the inlined target function IR syntax tree. The virtual machine can then further optimize the inlined target function IR syntax tree and compile it into machine code executable by the target processor. In other words, the compilation result obtained from inlining can include the inlined target function IR syntax tree, and further compilation can yield the machine code corresponding to the target function.
[0064] In another implementation, the compilation of the bytecode of hotspot functions and the generation of intermediate representations of these functions can be completed during the execution of the target program. For example, the virtual machine can use a different compilation thread than the thread running the target program to compile the bytecode of the hotspot functions according to their calling order in the hotspot function table within the target program, generating the corresponding intermediate representations. Since this compilation thread is different from the thread running the target program, the impact of the intermediate representation generation process on the target program's execution can be reduced, minimizing runtime resource contention.
[0065] In this embodiment, the hot function call order recorded in the hot function table is F1, F3, F2. During the execution of the target program, the runtime thread is responsible for executing the target program, and the compilation thread reads the bytecode of the corresponding functions in the order of F1, F3, F2, and then uses the bytecode parser and IR builder of the JIT compiler to convert the three bytecodes into IR syntax trees for caching. In this way, the hot functions that are more likely to be called first can generate intermediate representations first, thereby improving the response speed of subsequent inlining processing.
[0066] In some embodiments, after the target program has been run a first number of times, the virtual machine can obtain the running information of candidate functions in the target program that are not stored in the hot function table; based on the running information of the candidate functions, it can detect whether the candidate functions meet the second condition; if the candidate functions meet the second condition, the candidate functions are added to the hot function table to complete the update of the hot function table.
[0067] In some embodiments, after the target program has been run a first number of times, the virtual machine can obtain the running information of candidate functions in the target program that are not stored in the hot function table; based on the running information of the candidate functions, it can detect whether the candidate functions meet the second condition; if the candidate functions meet the second condition, the candidate functions are added to the hot function table.
[0068] Specifically, the virtual machine can use a run count counter to detect whether the target program has reached a certain number of runs. The run count counter can be incremented each time the target program starts, completes a full runtime cycle, or exits. Once the run count counter reaches the certain number, the virtual machine can query the function execution statistics table to obtain the execution information of candidate functions in the target program that are not stored in the hot function table. The function execution statistics table can be stored in the virtual machine's runtime memory, a local file, a database, or a configuration file, and can exist in the form of key-value pairs, hash tables, array tables, or database tables. For example, the key in the function execution statistics table can be a unique identifier for the function, and the value can be the execution statistics record corresponding to that function.
[0069] The execution information of candidate functions can include the number of times the candidate function is called, its call frequency, cumulative execution time, average execution time, and / or its performance impact. The virtual machine can determine whether a candidate function meets the second condition by comparing the number of times the candidate function is called with a second quantity, and / or comparing the call time of the candidate function with a first duration. If the candidate function meets the second condition, the virtual machine adds the candidate function to the hot function table so that the hot function table is dynamically updated; if the candidate function does not meet the second condition, the virtual machine does not add the candidate function to the hot function table, but can continue to retain the execution information of the candidate function for continued detection in subsequent statistical periods.
[0070] For example, after the target program P runs 10 times, the virtual machine discovers that function F4 was not originally stored in the hot function table, but the number of times function F4 is called reaches 3000, exceeding the second limit of 1000, or the average call duration of function F4 is 300 microseconds, exceeding the first duration of 200 microseconds. Therefore, it can be determined that function F4 meets the second condition, and function F4 is added to the hot function table. In this way, during subsequent execution of the target program, when the virtual machine detects function F4, it can inline it according to the handling methods for hot functions.
[0071] In some embodiments, the method may further include: disabling the preloading processing function in response to a shutdown command. The shutdown command may be input by the user or triggered by the virtual machine runtime environment, configuration file, or environment variables. Upon receiving the shutdown command, the virtual machine may disable the preloading processing function. After disabling the preloading processing function, the virtual machine no longer analyzes the bytecode of functions in the target program, and therefore no longer performs hotspot function table generation, intermediate representation pre-generation, or inlining processing based on the hotspot function table. Instead, it runs the target program using the conventional just-in-time (JIT) compilation method.
[0072] For example, users can set `enable_preload_inline=false` in the configuration file or disable the environment variable. When the virtual machine starts and reads this disabled state, it can skip the preloading process in S101. In this case, when the target program reaches a function, the virtual machine can determine whether the function needs to be inlined according to the regular JIT compilation process.
[0073] The following is an exemplary description of this application using a real-world scenario: Figure 3 A flowchart illustrating another compilation method provided in this application embodiment is shown below. Figure 3 As shown, the target program P includes functions F1, F2, F3, F4, and F5. The configuration file sets the bytecode size threshold to 128 bytes, the operand stack size threshold to 16 bytes, the call count threshold to 1000 times, the call duration threshold to 200 microseconds, and the performance impact threshold to 200 milliseconds. When the virtual machine performs preloading on the target program P, it analyzes the bytecode information of the functions in P. If the bytecode size of function F2 is 180 bytes and the operand stack size is 20 bytes, then F2 meets the bytecode characteristic conditions and can be identified as a hotspot function. During the execution of the target program P, the virtual machine uses a call counter and execution time statistician to collect function execution information. If function F1 is called 5000 times with an average execution time of 50 microseconds, its performance impact is 250 milliseconds, which is greater than the performance impact threshold, thus identifying F1 as a hotspot function. Similarly, if function F3 is called 1500 times, which is greater than the call count threshold of 1000 times, F3 is also identified as a hotspot function. The virtual machine stores the function information of F1, F2 and F3, such as function unique identifiers, bytecode addresses, and intermediate representation states, in the hot function table.
[0074] Before running the target program P, the virtual machine can pre-obtain the bytecode of F1, F2, and / or F3 based on the hot function table, and compile the obtained bytecode to generate intermediate representations of the corresponding hot functions. For example, the bytecode of F1 is converted into an IR syntax tree and cached, while the intermediate representation status of F1 in the hot function table is updated to indicate that an intermediate representation has been generated.
[0075] During the execution of the target program P, the virtual machine performs real-time monitoring of the target function to be executed. If the target function to be executed is F1, the virtual machine queries the hot function table based on the unique function identifier of F1. It determines that F1 exists in the hot function table, and since a hot function record corresponding to F1 exists, it confirms that the target function F1 exists in the hot function table. At this point, the virtual machine determines that the hot function corresponding to the target function F1 is F1 based on the hot function table and obtains the cached IR syntax tree for F1. If the target function to be executed does not exist in the hot function table, the virtual machine can process the target function according to the regular JIT compilation process.
[0076] When the target program reaches the location where F1 is called, the virtual machine copies the cached IR syntax tree and inlines the copied IR syntax tree to the corresponding call location. Specifically, the virtual machine can use the call node in the target function that originally called F1 as the inlining insertion point. Based on the actual parameter information at that call location, it replaces the parameter nodes in the copied IR syntax tree, and adjusts the local variable nodes, return nodes, and control flow nodes in the copied IR syntax tree based on the context information of the target function. Then, it embeds the adjusted IR syntax tree nodes into the call node location of the target function. After inlining, the call node in the IR syntax tree corresponding to the target function that originally pointed to F1 is replaced by the IR syntax tree node corresponding to F1, forming the inlined target function IR syntax tree. The virtual machine can then further optimize the inlined target function IR syntax tree and compile it into machine code executable by the target processor.
[0077] If, after multiple runs of the target program P, the virtual machine detects that the number of calls to F5, which was not originally stored in the hot function table, reaches 3000, or the call duration exceeds 200 microseconds, then F5 can be added to the hot function table to dynamically update it. If F5 does not meet the second condition, then F5 remains unadded to the hot function table. If a shutdown command is received, the preloading processing function is disabled, and the virtual machine runs the target program according to the regular JIT compilation process. If no shutdown command is received, the target program can continue to run, and real-time monitoring of the currently pending target functions continues.
[0078] In this way, during the execution of the target program P, the virtual machine can quickly determine whether the target function to be executed needs inlining by real-time detection of the hot function table, without having to perform a complete inlining check every time. Simultaneously, for hot functions with already generated IR syntax trees, the virtual machine can directly reuse the cached IR syntax trees, reducing the overhead of repeatedly reading bytecode and generating IR syntax trees. Furthermore, after inlining, the function call nodes in the target function are replaced by the IR syntax tree nodes corresponding to the hot functions, reducing function call jumps and call context maintenance overhead, thereby improving the compilation efficiency and function response speed of the target program.
[0079] In the compilation processing method provided in this application embodiment, preloading processing is performed on the target program to analyze the bytecode information of functions in the target program in advance, identify hot functions, and store the function information of the hot functions in a hot function table. Therefore, during the execution of the target program, the virtual machine can directly detect whether the target function to be executed needs to be inlined based on the hot function table, without needing to perform a complete inlining judgment on the target function again at runtime. This reduces runtime judgment overhead, speeds up the compilation response of the target function, and improves the running efficiency of the target program.
[0080] Example 2
[0081] This embodiment provides a compilation processing device. Figure 4 This is a schematic diagram of the structure of a compilation processing device provided in an embodiment of this application, as shown below. Figure 4 As shown, the compilation processing device includes: a preloading module 31, a detection module 32, and an inline module 33.
[0082] The preloading module 31 is used to perform preloading processing on the target program. The preloading processing includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table. Hot functions are functions in the target program whose call frequency, execution time, and / or performance impact meet preset conditions.
[0083] The detection module 32 is used to detect whether the target function to be run exists in the hot function table during the execution of the target program.
[0084] The inline module 33 is used to inline the target function when the detection module 32 detects that the target function exists in the hot function table, so that the target program can be compiled quickly.
[0085] In this embodiment, the target program can be a bytecode executable file. The target program may include multiple functions, each of which may have corresponding function information and bytecode information. The function information may include the function name, function identifier, function signature, bytecode address, and / or bytecode offset; the bytecode information may include the bytecode size, the size of the corresponding bytecode stack space, the bytecode sequence, the number of branch jump bytecodes, and / or the number of function call bytecodes.
[0086] In some embodiments, the preloading module 31 can read and parse the configuration file corresponding to the preloading process. The configuration file may include rules for determining hot functions, bytecode statistics rules, runtime statistics rules, and rules for storing the hot function table. The configuration file may include a precise configuration mode and a broad configuration mode. In precise configuration mode, the configuration file can directly record the function name, function signature, function identifier, or bytecode address that needs to be used as a hot function; in broad configuration mode, the configuration file can record bytecode characteristic conditions and / or runtime statistics conditions. The preloading module 31 can determine the hot functions in the target program based on the configuration file.
[0087] In some embodiments, the preloading module 31 can perform a global analysis of the target program. Global analysis refers to scanning and statistically analyzing multiple identifiable functions in the target program as a whole, rather than only analyzing currently executed functions or functions currently to be run.
[0088] In some embodiments, the preloading module 31 is specifically configured to: if the bytecode information of a function in the target program meets a first condition, then designate the function as a hotspot function. The first condition includes at least one of the following: the size of the function's bytecode is not less than a first threshold; the size of the function's bytecode's operation stack space is not less than a second threshold; the sequence of the function's bytecode contains branch jump bytecode; the function's bytecode contains function call bytecode.
[0089] In some embodiments, the preloading module 31 can also identify hot functions by combining function runtime statistics. Runtime statistics may include the number of function calls, call frequency, cumulative execution time, average execution time, and / or performance impact. The performance impact can be determined based on the number of function calls and the function execution time.
[0090] After identifying hot functions, the preloading module 31 can store the function information of the hot functions in a hot function table. The hot function table can be implemented using data structures such as hash tables, arrays, linked lists, tree structures, or database tables. Records in the hot function table can include function name, function signature, function identifier, bytecode address, bytecode characteristic information, runtime statistics, intermediate representation address, IR syntax tree cache address, and / or hot function status. The hot function table can be stored in the runtime memory of the compilation processing unit, or persistently stored in a local file, database, or configuration file.
[0091] The detection module 32 can search the hotspot function table based on the function name, function signature, function identifier, or bytecode address of the target function to be run. If a corresponding hotspot function record is found, the target function is determined to exist in the hotspot function table; if no corresponding hotspot function record is found, the target function is determined not to exist in the hotspot function table.
[0092] In some embodiments, the inlining module 33 is further configured to: before inlining the target function, determine the hotspot function corresponding to the target function according to the hotspot function table, and obtain the bytecode of the hotspot function; compile the bytecode of the hotspot function to generate an intermediate representation of the hotspot function. The intermediate representation is an internal data structure used to describe the control flow and operational semantics of the hotspot function.
[0093] Accordingly, the inlining module 33 inlines the objective function, including inlining the objective function based on the intermediate representation of the hotspot function.
[0094] In some embodiments, the intermediate representation includes an IR syntax tree. Specifically, inline module 33 is configured to: convert the bytecode of hot functions into an IR syntax tree and cache the IR syntax tree; during the just-in-time compilation of the target function, copy the cached IR syntax tree and inline the copied IR syntax tree to the call location corresponding to the target function.
[0095] In some embodiments, the preloading module 31 may compile the bytecode of at least a portion of the hot functions in the hot function table before running the target program, generating an intermediate representation of at least a portion of the hot functions. The at least a portion of the hot functions includes the hot functions corresponding to the target function.
[0096] In some embodiments, the preloading module 31 can, during the execution of the target program, use a different compilation thread than the thread running the target program to compile the bytecode of the hot functions according to the calling order of the hot functions in the hot function table within the target program, thereby generating corresponding intermediate representations. The fact that the compilation thread is different from the thread running the target program reduces the impact of the intermediate representation generation process on the execution of the target program.
[0097] In some embodiments, Figure 5 A schematic diagram of another compilation processing apparatus provided in the embodiments of this application is shown below. Figure 5 As shown, the compilation processing device may also include an update module 34.
[0098] The update module 34 is configured to, after the target program has been run a first number of times, obtain the running information of candidate functions in the target program that are not stored in the hot function table; based on the running information of the candidate functions, check whether the candidate functions meet the second condition; if the candidate functions meet the second condition, add the candidate functions to the hot function table.
[0099] The second condition includes: the number of function calls is not less than the second number; and / or, the function call duration is greater than the first duration.
[0100] In some embodiments, the update module 34 may also be configured to: after the target program has run a first number of times, detect whether the hot functions in the hot function table meet the third condition; if they do, remove the hot function from the hot function table and delete or release the intermediate representation corresponding to the hot function.
[0101] In some embodiments, the compilation processing apparatus may further include an execution module 35.
[0102] Execution module 35 is configured to disable preloading processing in response to a shutdown instruction. With preloading disabled, the compiler can stop generating hotspot function tables, pregenerating intermediate representations, or performing inlining based on hotspot function tables, and instead run the target program using the conventional just-in-time (JIT) compilation method.
[0103] In the compilation processing apparatus provided in this application embodiment, the preloading module 31 performs preloading processing on the target program, pre-determines hot functions, and stores the function information of the hot functions in a hot function table; the detection module 32 detects whether the target function to be run exists in the hot function table during the execution of the target program; and the inlining module 33 performs inlining processing on the target function when it exists in the hot function table. Therefore, the target program does not need to perform a complete inlining check every time it runs, which reduces the check overhead and improves the function response speed and the running efficiency of the target program.
[0104] Example 3
[0105] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device may include: transceiver 121, processor 122, and memory 123.
[0106] Processor 122 executes computer execution instructions stored in memory, causing processor 122 to perform the scheme in the above embodiments. Processor 122 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0107] The memory 123 is connected to the processor 122 via the system bus and completes communication between them. The memory 123 is used to store computer program instructions.
[0108] Transceiver 121 can be used to obtain the task to be run and its configuration information.
[0109] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.
[0110] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.
[0111] This application also provides a chip for executing instructions, which is used to execute the technical solution of the compilation processing method in the above embodiments.
[0112] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the compilation processing method described in the above embodiments.
[0113] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the compilation processing method in the above embodiments.
[0114] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.
[0115] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.
[0116] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.
[0117] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.
[0118] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.
[0119] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.
[0120] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0121] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.
[0122] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic control unit or main control device.
[0123] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A compilation processing method, characterized in that, The method includes: Perform preloading processing on the target program; the preloading processing includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table; During the execution of the target program, the target functions to be executed are detected in real time in the hot function table; If the target function is detected to exist in the hotspot function table, the target function is inlined to enable the target program to be compiled quickly.
2. The method according to claim 1, characterized in that, The method further includes: determining the hotspot function corresponding to the target function according to the hotspot function table, and obtaining the bytecode of the hotspot function; compiling the bytecode of the hotspot function to generate an intermediate representation of the hotspot function; Then, the step of inlining the objective function includes: inlining the objective function based on the intermediate representation of the hotspot function.
3. The method according to claim 2, characterized in that, The intermediate representation for generating the hotspot function includes: Before running the target program, the bytecode of at least some of the hot functions in the hot function table is compiled to generate an intermediate representation of the at least some hot functions; Wherein, at least some of the hotspot functions include hotspot functions corresponding to the objective function.
4. The method according to claim 2, characterized in that, The intermediate representation for generating the hotspot function includes: During the execution of the target program, a compilation thread different from the thread in which the target program resides is run. The bytecode of each hot function in the hot function table is compiled according to the calling order in the target program to generate the corresponding intermediate representation.
5. The method according to claim 2, characterized in that, The intermediate representation includes an IR syntax tree; the process of compiling the bytecode of the hotspot function to generate the intermediate representation of the hotspot function includes: converting the bytecode of the hotspot function into the IR syntax tree and caching it; The inlining of the target function based on the intermediate representation of the hotspot function includes: during the just-in-time compilation of the target function, copying the cached IR syntax tree and inlining the copied IR syntax tree to the call location corresponding to the target function, so as to embed the IR syntax tree of the hotspot function into the compilation structure corresponding to the target function.
6. The method according to claim 1, characterized in that, The determination of hotspot functions in the target program based on bytecode information includes: If the bytecode information of a function satisfies a first condition, the function is designated as the hotspot function; the first condition includes at least one of the following: The size of the bytecode of the function is not less than the first threshold; The size of the bytecode operation stack space of the function is not less than the second threshold. The sequence of bytecode for the function contains branch jump bytecode; The bytecode of the function contains the bytecode of the function call.
7. The method according to claim 1, characterized in that, The method further includes: After the target program has been run a certain number of times, the running information of candidate functions in the target program that are not stored in the hot function table is obtained; Based on the runtime information, it is detected whether the candidate function meets the second condition; if it does, the candidate function is added to the hotspot function table, thereby updating the hotspot function table.
8. A compilation processing apparatus, characterized in that, The device includes: A preloading module is used to perform preloading processing on the target program; the preloading processing includes: analyzing the bytecode information of functions in the target program, identifying hot functions in the target program, and storing the function information of the hot functions in a hot function table; the hot functions are functions in the target program whose call frequency, execution time, and / or performance impact meet preset conditions; The detection module is used to detect the target function to be run in the hot function table in real time during the execution of the target program. The inline module is used to inline the target function if it is detected that the target function exists in the hot function table, so that the target program can be compiled quickly.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.