De-optimization control method and device

Abstract

The embodiment of the invention discloses a de-optimization control method and device. The method comprises the following steps: statically analyzing byte codes of an application program to obtain a dependency record, storing the dependency record in a memory of a Java virtual machine, obtaining a program Java Agent for modifying the byte codes in a running process of the application program, and when the byte codes are detected to be modified, according to the dependency record, storing the application program Java Agent in the memory of the Java virtual machine. And carrying out local de-optimization on the currently modified byte code and the dependent class. Therefore, the dependency relationship between the classes is analyzed and obtained based on the application program runtime, the dependency record is generated, and precise and smaller-range de-optimization is realized through the dependency record, so that the negative influence of de-optimization caused by a byte code modification technology during runtime is reduced, the performance fluctuation of a processor caused by de-optimization can be reduced, and the performance of the processor is improved. And the usability of related products is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a deoptimization control method and device. Background Art

[0002] In the field of computer technology, the Java programming language is widely used in various scenarios. Java programs are compiled into bytecodes and executed by the Java Virtual Machine (JVM), ensuring the security and portability of the code. As application requirements grow, bytecode modification is required in many scenarios to enhance functionality.

[0003] However, bytecode modification may trigger the deoptimization mechanism of the Java virtual machine, causing the business process to undergo a large amount of recompilation work, resulting in relatively large performance fluctuations in the processor. Summary of the invention

[0004] In view of this, the purpose of an embodiment of the present invention is to provide a deoptimization control method and device, which obtains the dependency relationship between classes based on the runtime analysis of the application, generates dependency records, and realizes accurate and smaller-scale deoptimization through the dependency records, thereby reducing the negative impact of deoptimization brought by runtime bytecode modification technology, reducing the performance fluctuations of the processor caused by deoptimization, and improving the availability of related products.

[0005] In a first aspect, an embodiment of the present invention provides a deoptimization control method, the method comprising:

[0006] Obtaining dependency records by statically analyzing the bytecode of the application, wherein the dependency records include dependency relationships between classes;

[0007] Storing the dependency record in the memory of the Java virtual machine;

[0008] Obtaining a Java Agent, wherein the Java Agent is a program for modifying bytecodes;

[0009] When bytecode modification is detected, local deoptimization is performed on the currently modified bytecode and dependent classes according to the dependency record.

[0010] In some embodiments, when bytecode modification is detected, locally deoptimizing the currently modified bytecode and dependent classes according to the dependency record includes:

[0011] Check whether dependency logging is enabled;

[0012] In response to enabling dependency recording, determining a target class corresponding to the currently modified bytecode;

[0013] Determine the class that the target class depends on according to the dependency record;

[0014] Locally deoptimize the currently modified bytecode and the dependent classes.

[0015] In some embodiments, the method further comprises:

[0016] Starting a Java virtual machine, wherein the Java virtual machine is used to provide an operating environment;

[0017] Loading at least one precompiled class file in the Java virtual machine, the class file containing bytecode compiled from Java source code;

[0018] Convert the bytecode in the class file into native machine code;

[0019] Run the application according to the entry point information in the class file.

[0020] In some embodiments, obtaining dependency records by statically analyzing the bytecode of the application program includes:

[0021] Extract dependencies between classes by statically analyzing the bytecode of the application;

[0022] Constructing the dependency record according to the dependency relationship;

[0023] Dynamic tracking is performed by detecting class loading and / or compiling actions to update the dependency record.

[0024] In some embodiments, loading at least one precompiled class file in the Java virtual machine includes:

[0025] Locate the class file according to the given class name and class path;

[0026] Read the class file into memory and parse it into bytecode;

[0027] An object representing the class is created in the Java virtual machine using the bytecode.

[0028] In some embodiments, converting the bytecode in the class file into native machine code comprises:

[0029] Identify hot code by detecting the execution status of the application program;

[0030] The hotspot code is converted from bytecode form to native machine code by a just-in-time compiler.

[0031] In some embodiments, the method further comprises:

[0032] Intercept the original bytecode of the class file of the target class to be loaded;

[0033] Modify the intercepted target class bytecode according to the predefined rules or policies in the Java Agent;

[0034] The modified bytecode is provided to the Java virtual machine for loading and execution.

[0035] In some embodiments, the locally deoptimizing the currently modified bytecode and the dependent classes includes:

[0036] The currently modified bytecode and the bytecode of the dependent class are discarded to achieve local deoptimization.

[0037] In some embodiments, the method further comprises:

[0038] In response to dependency recording not being enabled, performing global deoptimization;

[0039] The global deoptimization is to discard all local machine codes.

[0040] In a second aspect, an embodiment of the present invention provides a deoptimization control device, the device comprising:

[0041] A dependency record acquisition unit, used to acquire a dependency record by statically analyzing the bytecode of the application program, wherein the dependency record includes dependency relationships between classes;

[0042] A dependency record storage unit, used for storing the dependency record in the memory of the Java virtual machine;

[0043] A modification program acquisition unit, used to acquire a Java Agent, wherein the Java Agent is a program for modifying bytecodes;

[0044] The local deoptimization unit is used to perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency record when a bytecode modification is detected.

[0045] In a third aspect, an embodiment of the present invention provides an electronic device, comprising a memory and a processor, wherein the memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method described in the first aspect.

[0046] In a fourth aspect, an embodiment of the present invention provides a computer program product, wherein the computer program product includes a computer program. When the computer program runs on a computer, the computer executes the method described in any one of the first aspects above.

[0047] In a fifth aspect, an embodiment of the present invention provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method described in the first aspect is implemented.

[0048] The technical solution of the embodiment of the present invention performs static analysis on the bytecode of the application to obtain dependency records, which include dependency relationships between classes, store the dependency records in the memory of the Java virtual machine, obtain the program Java Agent for modifying the bytecode during the running of the application, and when the bytecode modification is detected, perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency records. Thus, the dependency relationships between classes are obtained based on the runtime analysis of the application, dependency records are generated, and accurate and smaller-scale deoptimization is achieved through the dependency records, thereby reducing the negative impact of deoptimization caused by runtime bytecode modification technology, reducing the performance fluctuations of the processor caused by deoptimization, and improving the availability of related products. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The above and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0050] Figure 1 is a flow chart of a deoptimization control method according to an embodiment of the present invention;

[0051] Figure 2 is a flow chart of loading class files according to an embodiment of the present invention;

[0052] Figure 3 is a flowchart of converting local machine code according to an embodiment of the present invention;

[0053] Figure 4 is a flowchart of obtaining dependency records according to an embodiment of the present invention;

[0054] Figure 5 is a flowchart of bytecode modification according to an embodiment of the present invention;

[0055] Figure 6 is a flowchart of a local deoptimization according to an embodiment of the present invention;

[0056] Figure 7 is a flow chart of a deoptimization control method according to another embodiment of the present invention;

[0057] Figure 8 is a schematic diagram of a deoptimization control device according to an embodiment of the present invention;

[0058] Fig. 9 is a schematic diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0059] The present application is described below based on embodiments, but the present application is not limited to these embodiments. In the detailed description of the present application below, some specific details are described in detail. It is possible for those skilled in the art to fully understand the present application without the description of these details. In order to avoid confusing the essence of the present application, known methods, processes, flows, components and circuits are not described in detail.

[0060] In addition, persons of ordinary skill in the art will appreciate that the drawings provided herein are for illustration purposes and are not necessarily drawn to scale.

[0061] Unless the context clearly requires otherwise, the words "include", "comprising" and similar words throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, the meaning is "including but not limited to".

[0062] In the description of this application, it should be understood that the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in the description of this application, unless otherwise specified, the meaning of "plurality" is two or more.

[0063] The solutions described in this specification and in the examples, if they involve the processing of personal information, will be processed on the premise of having a legal basis (such as obtaining the consent of the subject of personal information, or being necessary for the performance of a contract, etc.), and will only be processed within the scope of regulations or agreements. If a user refuses to process personal information other than the necessary information for basic functions, it will not affect the user's use of basic functions.

[0064] Java is a widely used object-oriented programming language. Java programs can run on any system with a Java Virtual Machine (JVM) installed, regardless of the underlying hardware or operating system. The Java language has features such as automatic garbage collection, powerful standard library support, and strict type checking, which ensures development efficiency and code quality.

[0065] The Java Virtual Machine (JVM) is an abstract computing engine that is one of the core components of the Java platform. The main functions of the Java Virtual Machine include loading, verifying, and executing Java compiled bytecodes. Each Java Virtual Machine instance is an independent process space, which provides an isolated environment and ensures the security and stability of Java applications. The Java Virtual Machine implements Just-In-Time Compilation (JIT), which converts bytecodes into native machine instructions to improve performance. At the same time, it is also responsible for functions such as memory management, thread scheduling, and exception handling. Different implementations of the Java Virtual Machine can be optimized for specific operating systems and hardware, thereby ensuring the cross-platform compatibility of Java programs.

[0066] Specifically, Java source code files are written using a text editor or an integrated development environment (IDE). These files contain class definitions, methods, and variables. Using a Java compiler, Java source code is compiled into bytecode files. The compiler checks for syntax errors and generates a bytecode instruction set that conforms to the Java virtual machine specification. When a Java application is started, the Java virtual machine first loads the necessary classes through a class loader. The class loader is responsible for reading bytecode files from disk or other sources and loading them into memory. The Java virtual machine has three main class loaders: the bootstrap class loader, the extension class loader, and the application class loader. After the class is loaded, the next step is the linking phase, which is divided into three sub-steps: verification, preparation, and parsing. Verification is to ensure that the format of the loaded class file is correct and will not endanger the security of the Java virtual machine. Preparation is to allocate memory for the static variables of the class and set default values; parsing is to convert symbolic references into direct references, that is, to determine the specific location of classes, fields, and methods. After that, bytecode execution occurs. The Java virtual machine initially executes bytecode instructions one by one in an interpreted manner. For frequently executed hot code segments, the Java virtual machine will enable Just-In-Time Compilation (JIT). The JIT compiler compiles frequently used bytecode segments into local machine code to improve execution efficiency. This process can be called optimization. This process is dynamic, which means that compilation is triggered only after the code is executed enough times. The code compiled by JIT can be executed directly by the processor without being interpreted.

[0067] However, when operations such as error detection and recovery, logging, performance monitoring, security protection, debugging, and optimization are required, the bytecode needs to be modified. Bytecode modification refers to changes made at the bytecode level of a Java program. Through bytecode modification, the insertion, deletion, or replacement of method bodies, fields, constructors, and other contents can be achieved before and after class loading. However, since bytecode modification may trigger the deoptimization mechanism of the Java virtual machine, the code that has been compiled into local machine code will be discarded and returned to the interpreted execution mode, which will cause a sharp increase in processor occupancy, especially when the bytecode is modified for the first time. For example, the changes caused by bytecode modification may destroy the optimization assumptions originally made by the Java virtual machine. Specifically, the Java virtual machine is based on certain assumptions during the compilation and optimization process, such as certain methods will not be rewritten or the class structure will not change. If these assumptions are changed through bytecode modification (for example, the method body or class structure is modified), the Java virtual machine needs to re-evaluate the effectiveness of these optimizations. Therefore, when a bytecode change is detected, the Java virtual machine may need to roll back the methods that have been compiled into machine code to the interpreted mode, or recompile these methods to ensure that they conform to the new bytecode logic. This process is called deoptimization. Deoptimization will cause a temporary drop in performance because interpreted execution is much slower than running machine code directly, and recompiling also consumes extra time and resources. In the prior art, deoptimization is generally performed globally, which discards all local machine code, resulting in increased processor usage and other performance issues.

[0068] In order to solve the above-mentioned increase in processor usage and other performance issues caused by deoptimization, one implementation method of the prior art is to avoid the impact of deoptimization by statically deploying Java Agent.

[0069] Java Agent is a special type of Java program introduced in Java SE 5 that can non-invasively modify the target application before it is started or during its operation. Java Agent uses the Instrumentation API to intercept the class loading process, allowing the class definition to be transformed before or after it is loaded into the Java virtual machine. Statically deployed Java Agent refers to a Java Agent that has been determined and configured before the application is started. This type of JavaAgent completes the necessary changes before the application is loaded into the Java virtual machine by modifying the class file or bytecode, thereby avoiding the performance and stability problems that may be caused by dynamic modifications at runtime. Statically deploying Java Agent requires adding some agent configuration to the command (cmdline) for the application to start, which requires source code modification. At the same time, the static deployment solution requires modifying the application startup command (cmdline), which requires the application to be restarted before the configuration takes effect.

[0070] In summary, when the bytecode is modified, especially for the code segments that have been optimized by the just-in-time compiler (JIT), if the assumptions of these codes change (for example, the method body or class structure is modified), the original optimization may no longer apply. At this time, the Java virtual machine will perform a deoptimization process, and the code compiled into the local machine code will fall back to the interpretation mode for execution, or recompile to adapt to the new logic. Since the interpretation execution is much slower than directly running the machine code, this may cause the processor performance to decline, and recompiling also requires additional time and resources. Therefore, in view of the problems caused by the deoptimization mechanism of the above prior art, an embodiment of the present invention provides a deoptimization control method, which can reduce the problems of increased processor utilization and performance degradation caused by the deoptimization mechanism after the bytecode is modified, and at the same time, the modification of the bytecode can be realized without modifying the source code and without restarting the application, thereby reducing the development difficulty and improving the response speed.

[0071] Specifically, Figure 1 It is a flowchart of a deoptimization control method according to an embodiment of the present invention. Figure 1The deoptimization control method shown is executed by a processor. Further, when the processor executes the deoptimization control method, the program running in the background can be divided into two parts, namely, a business process and a security tool, wherein the business process is used to load and run the application, that is, the following steps S101-S104 are executed by the business process. The security tool is used to obtain dependency records when loading and running the application, and when the Java Agent is obtained, it performs the modification and deoptimization process of the bytecode, that is, the following steps S105-S110 are executed by the security tool. Specifically, the deoptimization control method of an embodiment of the present invention includes the following steps:

[0072] Step S101, start the Java virtual machine.

[0073] In this embodiment, the Java virtual machine is used to provide an operating environment.

[0074] Specifically, when a user or another program requests to run a Java application, the Java Virtual Machine (JVM) is started. Starting a Java Virtual Machine means initializing an environment that can execute Java bytecodes. The Java Virtual Machine startup process includes setting initial parameters, such as heap memory size, class path, etc., and loading necessary core class libraries. In addition, the Java Virtual Machine also initializes its internal structures, such as the garbage collector and class loader system, to prepare for subsequent class file loading and application execution.

[0075] Step S102: Load at least one precompiled class file in a Java virtual machine.

[0076] In this embodiment, after the Java virtual machine is successfully started, at least one precompiled class file is loaded. Specifically, the Java virtual machine will start loading the class and other class files it depends on according to the main class name in the startup command. These class files are .class files generated by compiling source code by the Java compiler during the development phase. The Java virtual machine uses a class loader to find and load these precompiled class files into memory. The loading process may also include operations such as verifying the correctness of the class file format, preparing the class structure (such as allocating space for static variables), and resolving symbol references to specific memory addresses.

[0077] Specifically, Figure 2 1 is a flow chart of loading class files according to an embodiment of the present invention. Figure 2 As shown, loading at least one precompiled class file in a Java virtual machine includes the following steps:

[0078] Step S1021: locate the class file according to the given class name and class path.

[0079] In this embodiment, when the Java virtual machine needs to load a specific class, it first determines which class to load based on the given class name. The class name is a fully qualified name organized according to the package structure. Next, the Java virtual machine uses the class path, that is, the location of a series of directories or archive files (such as .jar or .zip files), to find the class file (.class file) containing the class. This process may involve checking the standard library, the application's own class files, and the class files in the third-party library. If the corresponding class file is found, then prepare to proceed to the next step.

[0080] Step S1022: read the class file into the memory and parse it into bytecode.

[0081] In this embodiment, after locating the class file, the Java virtual machine will read the contents of the class file into the memory. This includes not only a simple file reading operation, but also verification of the class file format to ensure that it complies with the format specification, thereby ensuring security and compatibility. Next, the Java virtual machine will parse the read binary data and convert it into an internal data structure representation, which describes the methods, fields and other properties of the class. In this process, bytecode instructions are extracted to prepare for subsequent execution. In addition, this step also involves part of the linking phase, such as resolving symbolic references to direct references.

[0082] Step S1023: Use the bytecode to create an object representing the class in the Java virtual machine.

[0083] In this embodiment, the Java virtual machine will create an object representing the class in memory based on the bytecode information obtained by parsing. This object is not an instantiated object, but a metadata object used to represent the class itself, usually referred to as a Class object. The Class object contains all information about the class, such as methods, fields, etc., and there will only be one Class object for each unique class. This object is managed and maintained internally by the Java virtual machine and can be accessed through the reflection API. After creating the Class object, the Java virtual machine can initialize static variables, execute static initialization blocks, and prepare for the instantiation of the class. At this point, the class has been successfully loaded into the Java virtual machine and can be used by the program.

[0084] Step S103: Convert the bytecode in the class file into local machine code.

[0085] In this embodiment, after the class file is loaded, the bytecode therein needs to be executed. However, since the bytecode is a platform-independent intermediate representation, it cannot be directly executed by computer hardware. Therefore, the Java virtual machine uses Just-In-Time Compilation (JIT) technology to compile part or all of the bytecode into local machine code related to the current operating platform. This process can improve program execution efficiency because the local machine code can be directly executed by the processor without interpreting each instruction.

[0086] Specifically, Figure 3 1 is a flowchart of converting local machine code according to an embodiment of the present invention. Figure 3 As shown, converting the bytecode in the class file into local machine code includes the following steps:

[0087] Step S1031, identifying hotspot codes by detecting the execution status of the application.

[0088] In this embodiment, the Java virtual machine uses performance monitoring and analysis technology to track the execution of the application program. This includes but is not limited to recording information such as the number of method calls, loop execution frequency, and method execution time. The performance monitoring mechanism in the Java virtual machine can be based on sampling, that is, regularly checking the program status; or it can be based on event-driven, that is, recording whenever a specific event (such as method entry / exit) occurs.

[0089] The process of identifying "hot code" usually refers to finding those frequently executed code segments or methods. These code segments have a significant impact on the overall application performance due to their high frequency of execution. The Java virtual machine pays special attention to these areas because they are the parts most likely to benefit from compilation optimization. For example, if a method is called thousands of times, or the code in a loop body is executed for a long time, then this part of the code will be considered a hot code.

[0090] Step S1032: convert the hotspot code from bytecode to native machine code through a just-in-time compiler.

[0091] In this embodiment, after determining the hot code, the Java virtual machine will use the Just-In-Time Compiler (JIT) to convert the hot code from bytecode to native machine code. The JIT compiler is a special compiler that works while the program is running, rather than completing all compilation work before the program is deployed like a traditional compiler.

[0092] During this process, the JIT compiler of the Java virtual machine will perform a series of optimization operations on the hot code, such as inlining small functions, eliminating redundant calculations, improving branch prediction, etc., to generate more efficient local machine instructions. These optimization measures can significantly improve the execution speed of the program. In addition, since JIT compilation is performed at runtime based on the actual execution path, it can make some optimization decisions that are difficult for static compilers to achieve, such as optimization for specific input data distribution.

[0093] It is important to note that not all bytecodes are JIT compiled. Only those that are considered hotspots go through this process, while other infrequently executed code continues to be executed in an interpreted manner. This ensures that critical parts get better performance while keeping most of the code responsive. In addition, as the program continues to run, the Java virtual machine may dynamically re-evaluate which code is hot and adjust the compilation strategy accordingly.

[0094] Through the above steps, the Java virtual machine can intelligently select and optimize the most critical parts of the program, thereby effectively improving the overall performance of the application.

[0095] Step S104: Run the application program according to the entry point information in the class file.

[0096] In this embodiment, after all classes are loaded and the key bytecodes have been converted to native machine code, the Java virtual machine starts the execution of the application according to the entry point information. Specifically, the Java virtual machine creates a new thread and then calls the entry point method on this thread, thereby officially starting the logical execution of the application. From this point on, the application runs according to its programming logic until a normal termination condition is encountered or an unhandled exception occurs.

[0097] Step S105: Obtain dependency records.

[0098] In this embodiment, obtaining dependency records refers to identifying and recording all dependency relationships within the application program and between the application program and external libraries. These dependency relationships are used for subsequent local deoptimization.

[0099] Specifically, Figure 4 FIG. 1 is a flowchart of obtaining dependency records according to an embodiment of the present invention. Figure 4 As shown, obtaining dependency records includes the following steps:

[0100] Step S1051: Extract dependencies between classes by statically analyzing the bytecode of the application.

[0101] In this embodiment, in order to obtain the dependencies of the application, it is first necessary to perform static analysis on the bytecode of the application. This process does not require running the application itself, but directly checks the contents of the compiled class files. The static analysis tool scans the instruction sequence in the bytecode to identify which classes are referenced, which methods are called, which fields are accessed, and other information. In this way, a preliminary dependency graph can be constructed, showing the direct or indirect dependencies between classes.

[0102] Step S1052: construct the dependency record according to the dependency relationship.

[0103] In this embodiment, a detailed dependency record is constructed based on the dependencies obtained from static analysis. This step involves organizing the raw data into a format that is easy to understand and use, such as a chart, list, or database entry. The dependency record should include, but is not limited to, the following information: class name, other classes it depends on (including third-party libraries), dependency type (such as inheritance, implementation interface, use of methods or properties), and possible circular dependency warnings. In addition, metadata such as version number, license information, etc. can be added for each dependency.

[0104] Step S1053: Dynamically track by detecting class loading and / or compiling actions to update the dependency record.

[0105] In this embodiment, static analysis alone cannot capture all dependencies, especially those that only appear under specific operating conditions. Therefore, it is also necessary to adopt a dynamic tracking method to monitor the behavior of the application during its actual operation. Specifically, the proxy mechanism or other similar technologies provided by the Java virtual machine can be used to intercept class loading events and compilation actions to monitor new dependencies in real time. When new dependencies are found or existing dependencies change, the dynamic tracking module will update the dependency record in a timely manner. This method ensures the accuracy and timeliness of the dependency record, and can keep it synchronized even in the face of complex runtime environments.

[0106] Furthermore, after the dependency record is obtained, the dependency record is added to the memory of the Java virtual machine using Inline Hook. Inline Hook is a programming technique for intercepting and modifying the execution flow of a function or method.

[0107] Step S106: Obtain Java Agent.

[0108] In this embodiment, the Java Agent is a program for modifying bytecodes.

[0109] Furthermore, Java Agent is a dynamically deployed Java Agent with dynamic injection characteristics, which means that Java Agent does not need to be specified when the application is started, but is "injected" into the Java virtual machine through certain mechanisms after the application is already running. The dynamic injection capability greatly increases flexibility because it allows different Java Agents to be introduced as needed at different life cycle stages of the application without restarting the application.

[0110] Specifically, when error detection and recovery, logging, performance monitoring, security protection, debugging, optimization and other operations are required, bytecode modification is required, and the embodiment of the present invention performs bytecode modification based on Java Agent. The method of generating Java Agent can be implemented based on various existing methods.

[0111] For example, in some embodiments, the process of generating a Java Agent involves writing, packaging, and configuring the Java Agent so that it can modify the bytecode when the application is started or running. Writing is to define a class for dynamic injection. This class is the core of the Java Agent, responsible for interacting with the Java virtual machine and executing the bytecode conversion logic, and then create a class for bytecode modification logic. This class can add custom bytecode modification logic, such as inserting log statements, performance monitoring code, etc. Packaging is to declare Java Agent properties, specify the Java Agent main class, so that the file can be used as a Java Agent, and use command line tools or build tools to package the above-generated Java Agent code and resources into a JAR file. Configuring a Java Agent refers to dynamically injecting a Java Agent.

[0112] Step S107: modify the bytecode.

[0113] In this embodiment, the target class is modified according to the Java Agent, and the target class is the class that needs to be intercepted.

[0114] Specifically, Figure 5 1 is a flowchart of bytecode modification in an embodiment of the present invention. Figure 5 As shown, the bytecode modification of the target class of the application includes the following steps:

[0115] Step S1071: intercept the original bytecode of the class file of the target class to be loaded.

[0116] In this embodiment, when modifying the bytecode, it is necessary to identify and select which classes will be the targets of the bytecode modification. Specifically, according to the predefined rules or policies in the Java Agent, the target class is determined, and the target class is the class that needs to be intercepted.

[0117] Specifically, after the Java Agent is injected into the Java virtual machine, the process of determining which classes need to be modified mainly depends on the rules and policies within the Java Agent. After the Java Agent is injected into the Java virtual machine, the Java Agent is started. When the Java Agent is started, it is initialized, such as reading configuration files, setting rules, etc. These rules will be used in the subsequent class matching process. The Java Agent will register an instance of the ClassFileTransformer interface with the Instrumentation object. Whenever the Java virtual machine is ready to load a new class, it will call the transformation method of this ClassFileTransformer. In the transformation method, the Java Agent determines whether the current class is the target class based on predefined rules and policies.

[0118] That is, the predefined rules or policies in the Java Agent clearly define the standards for the classes that need to be intercepted, which can be defined by class name, package path, annotations, interface implementation, etc. When the Java virtual machine is ready to load a new class, the transform() method (transformation) of ClassFileTransformer will be called. Inside this method, you can check the parameters of the passed class, and then use regular expressions, wildcards or other logic to determine whether it meets the preset rules and policies. If it meets the requirements, it is considered to be the target class.

[0119] After the target class is determined, the original bytecode of the target class is intercepted through the transform() method of the ClassFileTransformer interface. This method receives the original bytecode of the class to be loaded and allows access to it before modification.

[0120] Step S1072: modify the intercepted bytecode of the target class according to the predefined rules or policies in the Java Agent.

[0121] In this embodiment, necessary modifications are made to the intercepted bytecode according to the predefined rules or policies in the Java Agent. Common modifications include inserting log records, performance monitoring, security protection, debugging support, optimization, etc.

[0122] Among them, insert logging: add entry and exit log statements for key methods.

[0123] Performance Monitoring: Insert timing code at the beginning and end of methods to collect performance statistics.

[0124] Security protection: Verify the validity of input parameters and prevent attacks such as SQL injection.

[0125] Debugging support: Add breakpoints or customize exception handling logic to help developers debug problems more easily.

[0126] Optimization: Remove unnecessary code to reduce memory usage or increase execution speed.

[0127] Step S1073: Provide the modified bytecode to the Java virtual machine for loading and execution.

[0128] In this embodiment, the modified bytecode needs to be returned to the Java virtual machine so that it can continue the normal loading process. Specifically, the transform() method returns the modified bytecode array, and the Java virtual machine will use this version of the bytecode to create the corresponding Class object and initialize it, so that the application can run as expected.

[0129] Step S108: Enable dependency records.

[0130] In this embodiment, it is detected whether dependency records are enabled, and the dependency records include dependency relationships between classes.

[0131] Further, if step S105 is not performed to obtain the dependency record, the detection result is that the dependency record is not enabled. If step S105 is performed to obtain the dependency record, the detection result is that the dependency record is enabled.

[0132] Step S109: perform global deoptimization.

[0133] In this embodiment, in response to not enabling dependency recording, global deoptimization is performed, wherein the global deoptimization is to discard all local machine codes.

[0134] Step S110: perform local deoptimization.

[0135] In this embodiment, when bytecode modification is detected, local deoptimization is performed on the currently modified bytecode and dependent classes according to the dependency record.

[0136] Further, Figure 6 1 is a flow chart of local deoptimization in an embodiment of the present invention. Figure 6As shown, local deoptimization of the currently modified bytecode and dependent classes includes the following steps:

[0137] Step S1101: Determine the target class corresponding to the bytecode currently being modified.

[0138] Step S1102: Determine the class that the target class depends on according to the dependency record.

[0139] Step S1103: locally deoptimize the currently modified bytecode and the dependent classes.

[0140] Partially deoptimizing the currently modified bytecode and the dependent class includes: discarding the currently modified bytecode and the bytecode of the dependent class to achieve local deoptimization.

[0141] The embodiment of the present invention performs static analysis on the bytecode of the application to obtain dependency records, which include dependency relationships between classes, store the dependency records in the memory of the Java virtual machine, obtain the Java Agent program for modifying the bytecode during the running of the application, and when the bytecode modification is detected, perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency records. Thus, the dependency relationships between classes are obtained based on the runtime analysis of the application, dependency records are generated, and accurate and smaller-scale deoptimization is achieved through the dependency records, thereby reducing the negative impact of deoptimization caused by runtime bytecode modification technology, reducing the performance fluctuation of the processor caused by deoptimization, and improving the availability of related products.

[0142] Figure 6 FIG. 1 is a flow chart of a deoptimization control method according to another embodiment of the present invention. Figure 7 As shown, the deoptimization control method of the embodiment of the present invention includes the following steps:

[0143] Step S210: Obtain dependency records by statically analyzing the bytecode of the application, where the dependency records include dependency relationships between classes.

[0144] Step S220: Store the dependency record in the memory of the Java virtual machine.

[0145] Step S230: Obtain Java Agent, where the Java Agent is a program for modifying bytecodes.

[0146] Step S240: When bytecode modification is detected, local deoptimization is performed on the currently modified bytecode and dependent classes according to the dependency record.

[0147] In some embodiments, when bytecode modification is detected, locally deoptimizing the currently modified bytecode and dependent classes according to the dependency record includes:

[0148] Check whether dependency logging is enabled;

[0149] In response to enabling dependency recording, determining a target class corresponding to the currently modified bytecode;

[0150] Determine the class that the target class depends on according to the dependency record;

[0151] Locally deoptimize the currently modified bytecode and the dependent classes.

[0152] In some embodiments, the method further comprises:

[0153] Starting a Java virtual machine, wherein the Java virtual machine is used to provide an operating environment;

[0154] Loading at least one precompiled class file in the Java virtual machine, the class file containing bytecode compiled from Java source code;

[0155] Convert the bytecode in the class file into native machine code;

[0156] Run the application according to the entry point information in the class file.

[0157] In some embodiments, obtaining dependency records by statically analyzing the bytecode of the application program includes:

[0158] Extract dependencies between classes by statically analyzing the bytecode of the application;

[0159] Constructing the dependency record according to the dependency relationship;

[0160] Dynamic tracking is performed by detecting class loading and / or compiling actions to update the dependency record.

[0161] In some embodiments, loading at least one precompiled class file in the Java virtual machine includes:

[0162] Locate the class file according to the given class name and class path;

[0163] Read the class file into memory and parse it into bytecode;

[0164] An object representing the class is created in the Java virtual machine using the bytecode.

[0165] In some embodiments, converting the bytecode in the class file into native machine code comprises:

[0166] Identify hot code by detecting the execution status of the application program;

[0167] The hotspot code is converted from bytecode form to native machine code by a just-in-time compiler.

[0168] In some embodiments, the method further comprises:

[0169] Intercept the original bytecode of the class file of the target class to be loaded;

[0170] Modify the intercepted target class bytecode according to the predefined rules or policies in the Java Agent;

[0171] The modified bytecode is provided to the Java virtual machine for loading and execution.

[0172] In some embodiments, the locally deoptimizing the currently modified bytecode and the dependent classes includes:

[0173] The currently modified bytecode and the bytecode of the dependent class are discarded to achieve local deoptimization.

[0174] In some embodiments, the method further comprises:

[0175] In response to dependency recording not being enabled, performing global deoptimization;

[0176] The global deoptimization is to discard all local machine codes.

[0177] The embodiment of the present invention performs static analysis on the bytecode of the application to obtain dependency records, which include dependency relationships between classes, store the dependency records in the memory of the Java virtual machine, obtain the Java Agent program for modifying the bytecode during the running of the application, and when the bytecode modification is detected, perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency records. Thus, the dependency relationships between classes are obtained based on the runtime analysis of the application, dependency records are generated, and accurate and smaller-scale deoptimization is achieved through the dependency records, thereby reducing the negative impact of deoptimization caused by runtime bytecode modification technology, reducing the performance fluctuation of the processor caused by deoptimization, and improving the availability of related products.

[0178] Figure 8 Schematic diagram of a deoptimization control device according to an embodiment of the present invention. Figure 8As shown, the deoptimization control device of the embodiment of the present invention includes a dependency record acquisition unit 81, a dependency record storage unit 82, a modification program acquisition unit 83 and a local deoptimization unit 84. Among them, the dependency record acquisition unit 81 is used to obtain dependency records by statically analyzing the bytecode of the application, and the dependency record includes the dependency relationship between each class. The dependency record storage unit 82 is used to store the dependency record in the memory of the Java virtual machine. The modification program acquisition unit 83 is used to obtain a Java Agent, and the Java Agent is a program for modifying the bytecode. The local deoptimization unit 84 is used to perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency record when a bytecode modification is detected.

[0179] The embodiment of the present invention performs static analysis on the bytecode of the application to obtain dependency records, which include dependency relationships between classes, store the dependency records in the memory of the Java virtual machine, obtain the Java Agent program for modifying the bytecode during the running of the application, and when the bytecode modification is detected, perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency records. Thus, the dependency relationships between classes are obtained based on the runtime analysis of the application, dependency records are generated, and accurate and smaller-scale deoptimization is achieved through the dependency records, thereby reducing the negative impact of deoptimization caused by runtime bytecode modification technology, reducing the performance fluctuation of the processor caused by deoptimization, and improving the availability of related products.

[0180] Fig. 9 Schematic diagram of an electronic device according to an embodiment of the present invention. In this embodiment, the electronic device 9 includes a server, a terminal, etc. Fig. 9 As shown, the electronic device 9 includes: at least one processor 91; a memory 92 connected to the at least one processor 91 for communication; and a communication component 93 connected to the scanning device for communication, the communication component 93 receives and sends data under the control of the processor 91; wherein the memory 92 stores instructions executable by at least one processor 91, and the instructions are executed by at least one processor 91 to implement the above-mentioned deoptimization control method.

[0181] Specifically, the electronic device includes: one or more processors 91 and a memory 92, Fig. 9 A processor 91 is taken as an example. The processor 91 and the memory 92 may be connected via a bus or other means. Fig. 9In the example, the bus connection is used. The memory 92 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The processor 91 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions and modules stored in the memory 92, that is, realizing the above-mentioned deoptimization control method.

[0182] The memory 92 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store a list of options, etc. In addition, the memory 92 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 92 may optionally include a memory remotely arranged relative to the processor 91, and these remote memories may be connected to an external device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0183] One or more modules are stored in the memory 92, and when executed by one or more processors 91, the deoptimization control method in any of the above method embodiments is executed.

[0184] The above-mentioned product can execute the method provided in the embodiment of the present application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of the present application.

[0185] The embodiment of the present invention performs static analysis on the bytecode of the application to obtain dependency records, which include dependency relationships between classes, store the dependency records in the memory of the Java virtual machine, obtain the Java Agent program for modifying the bytecode during the running of the application, and when the bytecode modification is detected, perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency records. Thus, the dependency relationships between classes are obtained based on the runtime analysis of the application, dependency records are generated, and accurate and smaller-scale deoptimization is achieved through the dependency records, thereby reducing the negative impact of deoptimization caused by runtime bytecode modification technology, reducing the performance fluctuation of the processor caused by deoptimization, and improving the availability of related products.

[0186] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program, wherein the computer-readable program is used for a computer to execute part or all of the above method embodiments.

[0187] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including a number of instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0188] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A deoptimization control method, characterized in that: The method comprises: Obtaining dependency records by statically analyzing the bytecode of the application, wherein the dependency records include dependency relationships between classes; Storing the dependency record in the memory of the Java virtual machine; Obtaining a Java Agent, wherein the Java Agent is a program for modifying bytecodes; When bytecode modification is detected, local deoptimization is performed on the currently modified bytecode and dependent classes according to the dependency record.

2. The method according to claim 1, characterized in that When a bytecode modification is detected, locally deoptimizing the currently modified bytecode and the dependent classes according to the dependency record includes: Check whether dependency logging is enabled; In response to enabling dependency recording, determining a target class corresponding to the currently modified bytecode; Determine the class that the target class depends on according to the dependency record; Locally deoptimize the currently modified bytecode and the dependent classes.

3. The method according to claim 2, characterized in that The method further comprises: Starting a Java virtual machine, wherein the Java virtual machine is used to provide an operating environment; Loading at least one precompiled class file in the Java virtual machine, the class file containing bytecode compiled from Java source code; Convert the bytecode in the class file into native machine code; Run the application according to the entry point information in the class file.

4. The method according to claim 3, characterized in that Obtaining dependency records by statically analyzing the bytecode of the application program includes: Extract dependencies between classes by statically analyzing the bytecode of the application; Constructing the dependency record according to the dependency relationship; Dynamic tracking is performed by detecting class loading and / or compiling actions to update the dependency record.

5. The method according to claim 3, characterized in that: The step of loading at least one precompiled class file in the Java virtual machine comprises: Locate the class file according to the given class name and class path; Read the class file into memory and parse it into bytecode; An object representing the class is created in the Java virtual machine using the bytecode.

6. The method according to claim 3, characterized in that The converting the bytecode in the class file into native machine code comprises: Identify hot code by detecting the execution status of the application program; The hotspot code is converted from bytecode form to native machine code by a just-in-time compiler.

7. The method according to claim 2, characterized in that The method further comprises: Intercept the original bytecode of the class file of the target class to be loaded; Modify the intercepted target class bytecode according to the predefined rules or policies in the Java Agent; The modified bytecode is provided to the Java virtual machine for loading and execution.

8. The method according to claim 1, characterized in that The local deoptimization of the currently modified bytecode and the dependent classes includes: The currently modified bytecode and the bytecode of the dependent class are discarded to achieve local deoptimization.

9. The method according to claim 2, characterized in that: The method further comprises: In response to dependency recording not being enabled, performing global deoptimization; The global deoptimization is to discard all local machine codes.

10. A deoptimization control device, characterized in that: The device comprises: A dependency record acquisition unit, used to acquire a dependency record by statically analyzing the bytecode of the application program, wherein the dependency record includes dependency relationships between classes; A dependency record storage unit, used for storing the dependency record in the memory of the Java virtual machine; A modification program acquisition unit, used to acquire a Java Agent, wherein the Java Agent is a program for modifying bytecodes; The local deoptimization unit is used to perform local deoptimization on the currently modified bytecode and the dependent classes according to the dependency record when a bytecode modification is detected.

11. An electronic device comprising a memory and a processor, characterized in that: The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method according to any one of claims 1 to 9.

12. A computer program product, comprising a computer program, characterized in that: When the computer program is executed on a computer, the computer executes the method according to any one of claims 1 to 9.

13. A computer-readable storage medium storing computer program instructions, characterized in that: The computer program instructions, when executed by a processor, implement the method according to any one of claims 1 to 9.

Images