Cross-platform code snippet cutting optimization system
By using a cross-platform code snippet trimming and optimization system, bytecode and performance sampling techniques are employed to embed performance sampling points, collect and analyze performance data, and trim out code blocks with performance differences in Java programs. This solves the problems of inaccurate location and high overhead in existing technologies, and achieves efficient performance optimization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI JIAOTONG UNIV
- Filing Date
- 2024-11-19
- Publication Date
- 2026-05-19
AI Technical Summary
Existing technologies cannot accurately pinpoint the specific code blocks that cause performance differences when optimizing Java program performance. This is especially true in large-scale server code where monitoring and analysis are costly and neglects hardware-software co-optimization.
The cross-platform code snippet trimming and optimization system uses bytecode and performance sampling techniques to implant performance sampling points, collect and analyze performance data, trim out code blocks that cause performance differences, reproduce and iteratively analyze them on different platforms, and finally output target code blocks that meet the requirements.
By effectively cutting out the target code blocks that cause performance differences and reducing their size, the accuracy of location and analysis efficiency are improved, and system overhead is reduced.
Smart Images
Figure CN122064564A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a technology in the field of performance engineering, specifically a cross-platform code snippet trimming and optimization system. Background Technology
[0002] The performance of Java programs (such as excessive overhead, unreasonable instruction arrangement, and high memory usage) is affected by the program itself, the Java Virtual Machine, the operating system, and the hardware platform. The causes of performance problems are not limited to the code written by software developers; in fact, how the underlying hardware translates and executes this code also has an impact. When performance problems are detected in the source code, current performance engineering techniques mainly focus on optimizing the software code logic, neglecting the coordination between software and hardware, and cannot accurately pinpoint the specific code block and platform combination that causes the performance problem. Summary of the Invention
[0003] This invention addresses the shortcomings of existing technologies that rely on externally defined rule files, making it difficult to pinpoint specific code blocks affecting performance. Furthermore, when applied to large-scale server code, monitoring, collecting, and summarizing these rules incurs significant overhead. To address these shortcomings, a cross-platform code snippet trimming and optimization system is proposed. This system trims code snippets that cause performance differences during Java program execution, thus reproducing performance variations across different platforms (Java Virtual Machine, operating system, hardware platform). It is applicable to various testing and debugging techniques used to identify program defects, applied to Java program performance analysis, and automatically optimized for its application scenarios and effectiveness. Compared to existing technologies, this invention has greater versatility, requires no external dependencies, and can accurately locate code snippets causing performance differences.
[0004] This invention is achieved through the following technical solution:
[0005] This invention relates to a cross-platform code snippet trimming and optimization system, comprising: an implantation module, a collection module, a detection module, a reproduction module, and a filtering module, wherein: the implantation module uses bytecode and performance sampling techniques to implant performance sampling points into the Java source code to be processed; the collection module runs the Java source code with the implanted performance sampling points, collects performance data between adjacent performance sampling points during execution, and generates an execution performance log; the detection module analyzes the execution performance log and trims out the code blocks that cause performance differences; the reproduction module records the virtual machine state when the target code block starts executing, thereby achieving rapid startup of the target code block and ultimately trimming out a reduced-size target code block; the filtering module generates an input that causes performance differences in Java source code on two different target platforms.
[0006] The logs include: timestamps, performance sampling point method names, and method execution counts.
[0007] The aforementioned performance sampling refers to: by modifying the bytecode, specific points are injected into the JAVA source code. When the code runs to these points, performance test code is triggered to obtain the runtime performance information of each subroutine and record it in the form of logs.
[0008] This invention relates to a cross-platform code snippet trimming and optimization method based on the above-mentioned system. When a performance difference in Java source code is detected between two different target platforms, performance sampling points are implanted in the source code, the source code is divided into multiple code blocks, the performance data of each code block is collected, and the target code block causing the performance difference is analyzed and trimmed out. The above steps are executed iteratively, using the target code block as source code, to continue iterative analysis in order to reduce the size of the target code block, and finally output the target code block whose size meets the requirements and causes the performance difference. Technical effect
[0009] This invention implants performance sampling points into Java source code, collects execution performance data of code blocks during runtime, analyzes the performance information of each code block, and iteratively identifies the target code block causing performance issues. This process reduces the size and scale of the target code block to meet output requirements. Compared to existing technologies, this invention can effectively identify smaller target code blocks that cause performance differences. Attached Figure Description
[0010] Figure 1 This is a schematic diagram of the system of the present invention;
[0011] Figure 2 This is a schematic diagram of the module for reproduction;
[0012] Figure 3 This is a flowchart of the present invention;
[0013] Figure 4 This is a schematic diagram comparing the performance of different target platforms in the example.
[0014] Figure 5 This is a schematic diagram illustrating the performance profiling based on timestamps in an embodiment.
[0015] Figure 6 The program call diagram is for example;
[0016] Figure 7 This is a schematic diagram illustrating the effect of locating the target code block in the example.
[0017] Figure 8 This is a schematic diagram illustrating the effect of iteratively reducing the program size in an example embodiment;
[0018] Figure 9 This is a schematic diagram illustrating the overhead analysis results of an example. Detailed Implementation
[0019] like Figure 2 As shown in the figure, this embodiment relates to a cross-platform code snippet trimming and optimization system, including: an implantation module, a collection module, a detection module, a reproduction module, and a filtering module. The implantation module uses bytecode and performance sampling techniques to implant performance sampling points into the Java source code to be processed. The collection module runs the Java source code with the implanted performance sampling points, collects performance data between adjacent performance sampling points during execution, and generates an execution performance log. The detection module analyzes the execution performance log and trims out the code blocks that cause performance differences. The reproduction module records the virtual machine state when the target code block starts executing, thereby achieving rapid startup of the target code block and ultimately trimming out a reduced-size target code block. The filtering module generates an input from the Java source code that causes performance differences on two different target platforms.
[0020] The implantation module includes a parameter configuration unit, a performance sampling point implantation unit, a uniform implantation unit, and a filtering unit. Specifically: the parameter configuration unit determines the number, function, location, and implantation method of performance sampling points based on user-provided operating parameters; the performance sampling point implantation unit implants specific performance sampling points based on the information determined by the parameter configuration unit, obtaining the target program with the implanted performance sampling points; the uniform implantation unit implants performance sampling points into the source code when the user has not declared the location and implantation method; and the filtering unit filters the methods during performance sampling point implantation.
[0021] The aforementioned implantation refers to using the ASM framework to dynamically modify the bytecode of the source code, adding an additional custom instruction sequence before the execution of a specific method begins.
[0022] The implantation of the performance sampling points specifically includes:
[0023] S1: The uniform implantation unit sets a counter Count and runs the source code. Each time the uniform implantation unit detects a method call, it increments Count by 1. After the source code execution is complete, the uniform implantation unit calculates the value of Count / N, denoted as Interval, where N is the number of performance sampling points. The uniform implantation unit uses the value of Interval as the interval number of methods for implanting performance sampling points each time; that is, after each Interval method call, the uniform implantation unit implants a performance sampling point in the next method call.
[0024] S2: The uniform implantation unit sets the Count value to 0, creates a hash table HT with strings as keys and integers as values, and executes the source code again. During execution, whenever the uniform implantation unit detects a method call, it obtains the fully qualified method name PCF of the current method, where P, C, and F are the package name, class name, and method name, respectively. The uniform implantation unit checks whether the current name matches the user's filter. For example, if the user only requires analysis of the package named P, which has the same literal value as the package name of the current method, then the current method F meets the requirement.
[0025] S3: If the current method passes the filtering, the uniform implantation unit will increment both its key and Count value in HT by 1. If the value of Count is equal to Interval at this time, the uniform implantation unit will record the current method name and its value in HT as a string in an array, and set the Count value to 0. By repeating the above steps, when the source code execution ends, the uniform implantation unit will output all records to the log file.
[0026] The method filtering mentioned above refers to the filtering unit calculating the execution count of each method before implanting performance sampling points. During the specific implantation stage, if the current method's execution count is significantly higher than all methods (e.g., in the top 10), the filtering unit will prevent the performance sampling point implantation unit from implanting this method. This avoids frequent system calls to this method during subsequent module operation, which could negatively impact system performance. Furthermore, this logic also prevents a large number of invalid implantations of underlying basic methods.
[0027] The collection module includes a performance information recording unit and a log writing unit. The performance information recording unit records the execution performance information of the source code in an array in memory, and the log writing unit writes the information in the array to a file after the source code execution is completed.
[0028] The aforementioned recording refers to the following: The performance information recording unit sets up an array `stamps`, and records the timestamp of the start time of the source code execution in `stamps`. If the source code execution reaches the statement where the performance sampling point is inserted, the performance sampling code will be called to record the current timestamp, method name, and the number of times the current method has been executed in `stamps`, until the source code execution ends.
[0029] Preferably, both the performance information recording unit and the log writing unit are executed multiple times to eliminate errors and ensure the accuracy of the performance information.
[0030] The detection module includes: a log analysis unit, a target code block location unit, and a traceability analysis unit, wherein: The log analysis unit reads performance record information from the log files generated by the collection module and parses the execution performance information of each code block; the target code block location unit locates the target code block that may cause performance differences based on the performance data obtained by the log analysis unit and according to the pre-selected strategy; the traceability analysis unit accurately determines the target code block based on the cumulative nature of performance bottlenecks.
[0031] The parsing refers to: for each pair of adjacent performance sampling points in each log file, analyzing their timestamps. i and stamp i+1 Log analysis unit calculation time t i =stamp i+1 -stamp i This is the execution time of this code block (where i is the code block number). By performing the above processing on each log file, the log analysis unit calculates the average execution time E for each code block. i S and variance i For two different target platforms, the log analysis unit obtains performance data E. 1,i E 2,i S 1,i S 2,i (The subscripts 1 and 2 refer to two different target platforms).
[0032] The aforementioned positioning refers to the following: In the default strategy, for code block numbered i, the target code block positioning unit calculates the deviation of its average runtime on two different target platforms as (Ei,2-Ei,1) / Ei,1*100%. Thus, among code segments numbered 1 to n, the target code block positioning unit selects the code block with the largest deviation value as the target code block.
[0033] The precise determination refers to the following: if the target code block location unit has located the target code block Pi, the trace analysis unit examines Pi and several code blocks before it as a whole, integrates the performance data, and performs the same operation on the rest of the source code to locate the target code block again, thereby obtaining a more accurate target code block that causes the performance difference.
[0034] The reproduction module includes a source code reproduction unit, an iterative analysis unit, and a performance verification unit. The source code reproduction unit implements the implantation of source code, generation of virtual machine snapshot files, and fast startup based on the snapshot location. The iterative analysis unit re-executes the implantation, collection, and detection steps of the source code module to obtain a smaller target code block. If the size of this code block meets the output requirements, it is output as the final result; otherwise, it is treated as new source code for continued iterative analysis. The performance verification unit calculates the execution time of the JAVA source code after applying this system, compares it with the original execution time, and analyzes the additional time overhead brought by introducing this system.
[0035] The aforementioned source code implantation refers to the following: The source code reproduction unit locates the entry method InFunc and the exit method OutFunc of the current source code P0, and performs the following implantation: In the InFunc method, the source code reproduction unit implants additional code that stops the execution of P0 and records the current virtual machine state in the snapshot file; In the OutFunc method, the source code reproduction unit implants additional code to terminate the operation of P0; Between the InFunc and OutFunc methods, the source code reproduction unit implants performance sampling points.
[0036] The snapshot file refers to the process of executing the source code up to the InFunc point through the source code reproduction unit, injecting additional code to interrupt the program's execution, and recording the virtual machine state at this point in the snapshot file.
[0037] The aforementioned rapid startup refers to the source code reproduction unit repeatedly and rapidly starting P0 from InFunc. During subsequent execution, if the current method incorporates performance sampling points, the source code reproduction unit performs the same operations as the collection and detection modules, collecting and analyzing the execution performance of the source code. If the current method is OutFunc, the source code reproduction unit terminates the execution of P0.
[0038] The virtual machine state refers to: the system resource and memory usage during program execution, class loading information, JVM parameters, call stack information for each thread, process state, and garbage collection information.
[0039] like Figure 2 As shown, after trimming out a target code block P0, a smaller code block P1 is obtained in one iteration. To obtain P1, the reproduction module first locates the entry and termination methods of the target code block. When P0 executes to the entry method, it records the virtual machine state and generates a snapshot file. Subsequently, the module repeatedly starts the analysis of the P0 code block from this file, obtaining multiple sets of performance data. Based on this, it analyzes P0 to obtain the P1 code block that causes the performance difference.
[0040] The filtering module includes an input generation unit and a key code input filtering unit. The input generation unit generates valid inputs for the JAVA source code based on the input parameter list of the JAVA source code. When the valid inputs are running on two different target platforms, if the program paths and program coverage of the JAVA source code are similar, but the execution times differ significantly, then the input is considered an ideal input that could cause performance differences and is used as the filtering result. Otherwise, the input is returned to the input generation unit to regenerate the inputs.
[0041] The valid input is obtained in the following way:
[0042] S1: The input generation unit calculates the cumulative number of bytes N occupied by the Java source code input parameters, initializes a byte array arr of length N, and converts the initial inputs that cause performance differences into corresponding byte representations as the initial value of arr.
[0043] S2: When the system needs to provide new input for the source code, the input generation unit randomly changes the value of a random byte in arr to obtain a new byte array arr1. Based on the number of bytes n occupied by each instance in the source code's parameter list, it retrieves n consecutive bytes from arr1 each time, converts them into the corresponding instance value, and verifies whether it is valid input. If yes, it continues to retrieve the next instance value; otherwise, it repeats this step. Finally, the input generation unit obtains valid input from the Java source code.
[0044] like Figure 3 As shown, this embodiment presents an optimization method based on the above system, including:
[0045] Step 1: Filter key code inputs and implant performance sampling points into the JAVA source code to be processed;
[0046] Step 2: Divide the JAVA source code into multiple code blocks based on each performance sampling point obtained in Step 1. Simulate the operation of multiple code blocks on multiple different platforms based on key code inputs. Collect the running time during the operation to generate running logs.
[0047] Step 3: Compare the code blocks with the largest runtime deviations on different platforms in the runtime logs, and select them as candidate code blocks;
[0048] Step 4: For candidate code blocks, check if the block size is small enough to meet the output requirements. If not, return to Step 1 for further evaluation; otherwise, consider it a code block that causes performance differences. Output the code block to the platform (e.g., domestic chip) developers to assist them in diagnosing platform faults or improving the efficiency of the target platform.
[0049] Through specific experiments, optimizations were performed on both the host Linux virtual machine and a remote Linux server platform, using Apache Sunflow as the Java source code. For example... Figure 4 As shown in the figure, the horizontal axis subscripts represent individual methods, the green dots represent the running efficiency of each method on the x86 platform, and the blue dots represent the corresponding running efficiency on the ARM platform. Analysis reveals that some methods exhibit significant time performance differences across different target platforms.
[0050] like Figure 5 The diagram illustrates a strategy for performance profiling of method call chains. The system records the timestamps of the method's start and return times to calculate the method's runtime.
[0051] like Figure 6 As shown in the diagram, each number represents a single method, and several methods form a method call chain (for simplicity, the diagram assumes this call chain has no branches). When analyzing the call chain, the system dissects the execution time of each method in the call chain on the two target platforms to determine in which method or sub-call chain the performance difference is most likely located. Furthermore, assuming the system has already detected sub-call chain 45 as an abnormal call chain, due to the cumulative nature of the performance difference, the system will trace back from method 4 to determine if the complete abnormal call chain could be 345.
[0052] like Figure 7 As shown, the horizontal axis represents each code block, and the vertical axis represents the average runtime (microseconds). Blue and orange markers indicate the local virtual machine and the remote Linux server, respectively. Analysis reveals that, on the two different target platforms, the runtime deviation of code block 19 is particularly significant compared to other code blocks. Based on this, the system roughly concludes that the performance difference exists within this target code block.
[0053] like Figure 8 As shown, the runtime of the source code on two different target platforms was first examined, and a significant difference was detected (798 seconds and 530 seconds). Therefore, performance difference analysis was initiated using this source code. Through iterative analysis, the performance difference was narrowed down to a method call chain in the Color class from the Color.madd method to the Color.mul method. Therefore, it was initially determined that the performance bottleneck was caused by the Color class.
[0054] like Figure 9The diagram illustrates the additional overhead introduced by applying this system to analyze a specific Java source code. The program iterates seven times. `couting_time` and `inst_time` represent the overhead introduced by inserting performance sampling points into the program. `perfing_time` is the actual runtime (all time units are milliseconds). Calculations show that, excluding the overhead of inserting performance sampling points, approximately 7.4 times the runtime is required, similar to the number of iterations. However, due to the large size of the Java source code, the time overhead is primarily concentrated in the first iteration. Subsequent iterations have relatively low overhead. Therefore, the additional overhead introduced by this system is within an acceptable range.
[0055] Compared with existing technologies, this invention applies the insertion of performance sampling points and iterative analysis of target code blocks to ultimately extract the target code blocks that cause performance differences from the source code.
[0056] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.
Claims
1. A cross-platform code snippet trimming and optimization system, characterized in that, include: The system comprises an implantation module, a collection module, a detection module, a reproduction module, and a filtering module. Specifically: the implantation module uses bytecode and performance sampling techniques to implant performance sampling points into the Java source code to be processed; the collection module runs the Java source code with the implanted performance sampling points, collects performance data between adjacent performance sampling points during execution, and generates execution performance logs; the detection module analyzes the execution performance logs and prunes out the code blocks that cause performance differences; the reproduction module records the virtual machine state when the target code block starts executing, thereby enabling rapid startup of the target code block and ultimately pruning out a reduced-size target code block; and the filtering module generates an input from the Java source code that causes performance differences on two different target platforms. The logs include: timestamps, performance sampling point method names, and method execution counts; The aforementioned performance sampling refers to: by modifying the bytecode, specific points are injected into the JAVA source code. When the code runs to these points, performance test code is triggered to obtain the runtime performance information of each subroutine and record it in the form of logs.
2. The cross-platform code snippet trimming and optimization system according to claim 1, characterized in that, The implantation module includes a parameter configuration unit, a performance sampling point implantation unit, a uniform implantation unit, and a filtering unit. Specifically: the parameter configuration unit determines the number, function, location, and implantation method of performance sampling points based on user-provided operating parameters; the performance sampling point implantation unit implants specific performance sampling points based on the information determined by the parameter configuration unit, obtaining the target program with the implanted performance sampling points; the uniform implantation unit implants performance sampling points into the source code when the user has not declared the location and implantation method; and the filtering unit filters the methods during performance sampling point implantation.
3. The cross-platform code snippet trimming and optimization system according to claim 1, characterized in that, The collection module includes a performance information recording unit and a log writing unit. The performance information recording unit records the execution performance information of the source code in an array in memory, and the log writing unit writes the information in the array to a file after the source code execution is completed.
4. The cross-platform code snippet trimming and optimization system according to claim 1, characterized in that, The detection module includes a log analysis unit, a target code block location unit, and a traceability analysis unit. The log analysis unit reads performance record information from the log file generated by the collection module and parses the execution performance information of each code block. The target code block location unit locates the target code block that may cause performance differences based on the performance data obtained by the log analysis unit and a pre-selected strategy. The traceability analysis unit accurately determines the target code block based on the cumulative nature of performance bottlenecks.
5. The cross-platform code snippet trimming and optimization system according to claim 1, characterized in that, The reproduction module includes a source code reproduction unit, an iterative analysis unit, and a performance verification unit. The source code reproduction unit implements the implantation of source code, generation of virtual machine snapshot files, and fast startup based on the snapshot location. The iterative analysis unit re-executes the implantation, collection, and detection steps of the source code module to obtain a smaller target code block. If the size of this code block meets the output requirements, it is output as the final result; otherwise, it is treated as new source code for continued iterative analysis. The performance verification unit calculates the execution time of the JAVA source code after applying this system, compares it with the original execution time, and analyzes the additional time overhead brought by introducing this system.
6. The cross-platform code snippet trimming and optimization system according to claim 1, characterized in that, The filtering module includes an input generation unit and a key code input filtering unit. The input generation unit generates valid inputs for the JAVA source code based on the input parameter list of the JAVA source code. When the valid inputs are running on two different target platforms, if the program paths and program coverage of the JAVA source code are similar, but the execution times differ significantly, then the input is considered an ideal input that could cause performance differences and is used as the filtering result. Otherwise, the input is returned to the input generation unit to regenerate the inputs.
7. The cross-platform code snippet trimming and optimization system according to claim 2, characterized in that, The implantation of the performance sampling points specifically includes: S1: The uniform implantation unit sets a counter Count and runs the source code. Whenever the uniform implantation unit detects a method call, it increments Count by 1. After the source code execution is complete, the uniform implantation unit calculates the value of Count / N, which is denoted as Interval, where N is the number of performance sampling points. The uniform implantation unit will use the value of Interval as the interval number of methods for each performance sampling point implantation. That is, every Interval method call, in the next method call, the uniform implantation unit will implant a performance sampling point in that method. S2: The uniform implantation unit sets the Count value to 0, creates a hash table HT with strings as keys and integers as values, and executes the source code again. During execution, whenever the uniform implantation unit detects a method call, it obtains the full method name PCF of the current method, where P, C, and F are the package name, class name, and method name, respectively. The uniform implantation unit checks whether the current name meets the user's filter. For example, if the user only requires analysis of the package named P, which has the same literal value as the package name of the current method, then the current method F meets the requirements. S3: If the current method passes the filter, the uniform implantation unit will increment its key value and count value in HT by 1. If the value of count is equal to Interval at this time, the uniform implantation unit will record the current method name and its value range value in HT as a string in the array and set the count value to 0. By repeating the above steps, when the source code execution ends, the uniform implantation unit will output all records to the log file. The filtering of methods refers to the following: before the performance sampling point is implanted, the filtering unit calculates the number of times each method is executed. During the specific implantation stage, if the number of times the current method is executed is significant among all methods, the filtering unit will prevent the performance sampling point implantation unit from implanting this method. This is to avoid the system frequently calling this method during the subsequent operation of the module, which would affect the system's performance. In addition, this logic can also avoid a large number of invalid implantations of underlying basic methods.
8. The cross-platform code snippet trimming and optimization system according to claim 4, characterized in that, The parsing refers to: for each pair of adjacent performance sampling points in each log file, analyzing their timestamps. i and stamp i+1 Log analysis unit calculation time t i =stamp i+1 -stamp i As the execution time of this code block (where i is the code block number), the log analysis unit calculates the average execution time E of each code block by performing the above processing on each log file. i S and variance i For two different target platforms, the log analysis unit obtains performance data E. 1,i E 2,i S 1,i S 2,i (The subscripts 1 and 2 refer to two different target platforms); The aforementioned positioning refers to the following: In the default strategy, for code block numbered i, the target code block positioning unit calculates the deviation of its average running time on two different target platforms as (Ei,2-Ei,1) / Ei,1*100%. Thus, among code segments numbered 1 to n, the target code block positioning unit selects the code block with the largest deviation value as the target code block. The precise determination refers to the following: if the target code block location unit has located the target code block Pi, the trace analysis unit examines Pi and several code blocks before it as a whole, integrates the performance data, and performs the same operation on the rest of the source code to locate the target code block again, thereby obtaining a more accurate target code block that causes the performance difference.
9. The cross-platform code snippet trimming and optimization system according to claim 5, characterized in that, The aforementioned injection of source code refers to: the source code reproduction unit locates the entry method InFunc and the exit method OutFunc of the current source code P0, and performs the following injection: In the InFunc method, the source code reproduction unit injects additional code, which will stop the execution of P0 and record the virtual machine state at this time in the snapshot file; In the OutFunc method, the source code reproduction unit injects additional code to terminate the execution of P0; between the InFunc method and the OutFunc method, the source code reproduction unit injects performance sampling points. The snapshot file refers to the process of executing the source code up to the InFunc point through the source code reproduction unit, injecting additional code to interrupt the program's execution, and recording the virtual machine state at this point in the snapshot file. The aforementioned fast startup refers to the following: the source code reproduction unit repeatedly starts P0 from InFunc. During subsequent execution, if the current method has performance sampling points, the source code reproduction unit performs the same operations as the collection module and the detection module to collect and analyze the execution performance of the source code. If the current method is OutFunc, the source code reproduction unit terminates the execution of P0. The virtual machine state refers to: the system resource and memory usage during program execution, class loading information, JVM parameters, call stack information for each thread, process state, and garbage collection information.
10. The cross-platform code snippet trimming and optimization system according to claim 6, characterized in that, The valid input is obtained in the following way: S1: The input generation unit calculates the cumulative number of bytes N occupied by the Java source code input parameters, initializes a byte array arr of length N, and converts the initial inputs that cause performance differences into corresponding byte representations as the initial value of arr; S2: When the system needs to provide a new input for the source code, the input generation unit randomly changes the value of a random byte in arr to obtain a new byte array arr1. According to the number of bytes n occupied by each instance in the parameter list of the source code, it obtains n consecutive bytes in arr1 each time, converts them into the corresponding instance value, and verifies whether it is a valid input. If it is, it continues to obtain the next instance value; otherwise, it repeats this step. Finally, the input generation unit obtains the valid input of the JAVA source code.
11. A cross-platform code fragment trimming and optimization method based on the system described in any one of claims 1-10, characterized in that, When performance differences in Java source code are detected on two different target platforms, performance sampling points are inserted into the source code. The source code is divided into multiple code blocks, and the performance data of each code block is collected. The target code block causing the performance difference is then analyzed and removed. The above steps are repeated, and the target code block is used as source code for iterative analysis to reduce its size. Finally, the target code block that meets the size requirements and causes the performance difference is output.