De-optimization control method and device

Abstract

The embodiment of the invention discloses a de-optimization control method and device. When an application program is started through a service process, an agent tool is loaded and started, a dependency record is obtained through the agent tool, the dependency record comprises the dependency relation between all method functions, a program Java Agent used for modifying byte codes is obtained through a safety tool, and the program Java Agent is used for modifying the byte codes. And performing local de-optimization on the currently modified byte code and the dependent method function according to the Java Agent and the dependency record. Therefore, based on the agent tool, the dependency relationship of the method function level is obtained, 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 operation is reduced, the utilization rate of computing resources can be improved, and the computing efficiency is improved. Performance fluctuation of the processor caused by de-optimization is reduced, and the response speed and stability of the system are 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. However, bytecode modification may trigger the deoptimization mechanism of the Java Virtual Machine, resulting in performance degradation.

[0003] In the prior art, the problems caused by deoptimization are generally solved through global deoptimization or class-based local deoptimization. Global deoptimization is to discard all compiled local machine codes, and class-based local deoptimization is to discard the compiled local machine codes of the entire class and its dependent classes.

[0004] However, global deoptimization or class-based local deoptimization will lead to a large waste of computing resources. At the same time, it will cause a large amount of recompilation work for the business process, resulting in relatively large performance fluctuations in the processor, affecting the response speed and stability of the system. Summary of the invention

[0005] In view of this, an object of an embodiment of the present invention is to provide a deoptimization control method and device, which can improve the utilization of computing resources, reduce the fluctuation of processor usage, and improve the response speed and stability of the system.

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

[0007] The business process loads and enables the proxy tool when the application starts;

[0008] The business process obtains the dependency record through the proxy tool, and the dependency record includes the dependency relationship between various method functions;

[0009] The security tool obtains a Java Agent, where the Java Agent is a program for modifying bytecodes;

[0010] The security tool performs local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependent records.

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

[0012] The business process starts a Java virtual machine, which is used to provide an operating environment;

[0013] The service process loads at least one precompiled class file in the Java virtual machine, wherein the class file includes bytecode compiled from Java source code;

[0014] The business process converts the bytecode in the class file into local machine code.

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

[0016] The business process locates the class file according to the given class name and class path;

[0017] The business process reads the class file into memory and parses it into bytecode;

[0018] The business process uses the bytecode to create an object representing the class in the Java virtual machine.

[0019] In some embodiments, the business process converting the bytecode in the class file into native machine code includes:

[0020] The business process detects the execution of the application and identifies the hot code;

[0021] The service process converts the hotspot code from bytecode to native machine code through a just-in-time compiler.

[0022] In some embodiments, the business process obtaining the dependency record through the proxy tool includes:

[0023] The business process inserts a hook point through the proxy tool based on the inline hook technology when the just-in-time compiler compiles the method function, so as to obtain the dependency relationship between each method function;

[0024] The business process generates the dependency record based on the dependency relationship.

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

[0026] The security tool modifies the bytecode of the application program according to the Java Agent.

[0027] In some embodiments, the security tool modifies the bytecode of the application according to the Java Agent, including:

[0028] The security tool intercepts the original bytecode of the class file of the target class to be loaded;

[0029] The security tool modifies the bytecode of the target class according to the predefined rules or policies in the Java Agent;

[0030] The security tool provides the modified bytecode to the Java virtual machine for loading and execution.

[0031] In some embodiments, the security tool locally deoptimizes the currently modified bytecode and dependent method functions according to the Java Agent and the dependency record, including:

[0032] The security tool determines the target method function corresponding to the currently modified bytecode;

[0033] The security tool determines the method function that the target method function depends on according to the dependency record;

[0034] The security tool performs local deoptimization on the currently modified bytecode and dependent method functions.

[0035] In some embodiments, the security tool locally deoptimizes the currently modified bytecode and dependent method functions, including:

[0036] The currently modified bytecode and the local machine code corresponding to the dependent method function are discarded to achieve local deoptimization.

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

[0038] The proxy tool loading unit is used to load and enable the proxy tool when the application starts;

[0039] A dependency record acquisition unit, used to acquire a dependency record through the proxy tool, wherein the dependency record includes dependency relationships between various method functions;

[0040] A modification program acquisition unit, used to acquire a Java Agent, wherein the Java Agent is a program used to modify bytecodes;

[0041] The local deoptimization unit is used to perform local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependent record.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] The technical solution of the embodiment of the present invention is to load and enable the proxy tool when the application is started through the business process, and obtain the dependency record through the proxy tool, the dependency record includes the dependency relationship between each method function, obtain the program Java Agent for modifying the bytecode through the security tool, and perform local deoptimization on the currently modified bytecode and the dependent method function according to the Java Agent and the dependency record. Thus, the dependency relationship at the method function level is obtained based on the proxy tool, the dependency record is generated, and the precise and smaller range of deoptimization is achieved through the dependency record, so as to reduce the negative impact of deoptimization caused by the runtime bytecode modification technology, improve the utilization rate of computing resources, reduce the performance fluctuation of the processor caused by deoptimization, and improve the response speed and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] 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:

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

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

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

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

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

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

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

[0054] Figure 8 is a schematic diagram of a bytecode modification device according to an embodiment of the present invention;

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

[0056] 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.

[0057] 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.

[0058] 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".

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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 recompilation also consumes extra time and resources. In the prior art, the problems caused by deoptimization are generally solved through global deoptimization or class-based local deoptimization. Global deoptimization is to discard all compiled local machine codes, and class-based local deoptimization is to discard the compiled local machine codes of the entire class and its dependent classes. However, global deoptimization or class-based local deoptimization will lead to a large waste of computing resources, and at the same time, it will also cause the processor utilization rate to fluctuate greatly, affecting the response speed and stability of the system.

[0065] 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 Java 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.

[0066] 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.

[0067] 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. Furthermore, 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. The business process is used to load and run the application. At the same time, when the application starts, the proxy tool is loaded and enabled, and the dependency record is obtained through the proxy tool. The dependency record includes the dependency relationship between each method function, that is, the following steps S101-S1016 are executed by the business process. The security tool is used to obtain the dependency record when loading and running the application, and when the Java Agent is obtained, it executes the modification and deoptimization process of the bytecode, that is, the following steps S107-S109 are executed by the security tool. Specifically, the deoptimization control method of an embodiment of the present invention includes the following steps:

[0068] Step S101: The business process starts an application.

[0069] In this embodiment, launching an application means that a user or another program requests to run a Java application.

[0070] Step S102: The business process starts a Java virtual machine.

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

[0072] 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.

[0073] Step S103: The business process loads and activates the proxy tool.

[0074] In this embodiment, when the application is started, the proxy tool is loaded and enabled, wherein the proxy tool can automatically enable the dependency recording function when the application is started.

[0075] In some embodiments, the agent tool may be implemented by a Java Agent.

[0076] 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. Usually, Java Agent completes the necessary changes before the application is loaded into the Java virtual machine by modifying the class file or bytecode, thus avoiding the performance and stability problems that may be caused by dynamic modification at runtime.

[0077] The proxy tool of the embodiment of the present invention is implemented by Java Agent technology, but the function that can be implemented is not to modify the code, but to obtain dependencies. Specifically, the proxy tool of the embodiment of the present invention is a Java Agent that has been determined and configured before the application is started. Specifically, the Java Agent of the proxy tool needs to add some Java agent configurations to the application startup command (cmdline), and these configurations are called command lines. That is to say, when a Java application is started through the command line or other means, the Java virtual machine parses the provided command line parameters before starting. If the java agent parameters are specified in the command line, then at this early stage, the Java virtual machine will load the specified JavaAgent JAR file and enable the Java Agent. This means that the Java Agent will be loaded and enabled after the Java virtual machine completes its core initialization, but before the user-defined application class is loaded.

[0078] Step S104: The business process loads at least one precompiled class file in the Java virtual machine.

[0079] In this embodiment, after the Java virtual machine is successfully started, at least one precompiled class file (.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, and .class files are bytecodes. 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.

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

[0081] Step S1041: The business process locates the class file according to the given class name and class path.

[0082] 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.

[0083] Step S1042: The business process reads the class file into memory and parses it into bytecode.

[0084] 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.

[0085] Step S1043: The business process uses the bytecode to create an object representing the class in the Java virtual machine.

[0086] 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.

[0087] Step S105: The business process converts the bytecode in the class file into local machine code.

[0088] 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.

[0089] 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:

[0090] Step S1051: The business process identifies hotspot codes by detecting the execution status of the application.

[0091] 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.

[0092] 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.

[0093] Step S1052: The business process converts the hotspot code from bytecode to native machine code through a just-in-time compiler.

[0094] 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.

[0095] 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.

[0096] 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 sections get the best 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.

[0097] 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.

[0098] In some embodiments, after all classes are loaded and 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.

[0099] Step S106: The business process obtains dependency records.

[0100] In this embodiment, the business process obtains a dependency record through the proxy tool, and the dependency record includes the dependency relationship between various method functions, wherein the method function is a part of code in a class, which is used to perform a specific task or calculation.

[0101] Specifically, in Java, a class is one of the basic building blocks of object-oriented programming, which defines the blueprint or template of an object. A class contains data members (attributes or fields) and method functions (behaviors), which together describe the states that objects (instances) of the class can have and the operations that can be performed. Among them, a method function is a block of code that performs a specific task or calculation. When the Java virtual machine loads a class, it reads the method information in the class file, including the method name, parameter list, return type, etc. At the same time, the bytecode of the method body is parsed and compiled when the method is called for the first time.

[0102] Furthermore, the embodiment of the present invention refines the dependency record granularity of the JIT (Just-In-Time Compiler) from the class level to the method function level through the Inline Hook technology.

[0103] 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:

[0104] Step S1061: The business process inserts hook points into the just-in-time compiler when compiling method functions through the proxy tool based on the inline hook technology, so as to obtain the dependency relationship between various method functions.

[0105] In this embodiment, the JIT compiler is responsible for converting Java bytecodes into native machine code and optimizing these codes at runtime to improve performance. During this process, the JIT may perform inline optimization on certain classes or method functions, which means that it will directly embed the called method function into the caller, thereby reducing the calling overhead. Dependencies refer to the state of specific classes, fields, or methods that the JIT compiler depends on during the compilation process. If these dependencies change (for example, a method is redefined), the optimized code generated by the JIT may no longer be valid, so Java needs to be able to detect these changes and take appropriate measures, such as recompiling the affected code.

[0106] Inline Hook is a programming technique used to intercept and modify the execution flow of a function or method. In the Java environment, this technique can be implemented in the following ways: Java Instrumentation API (Java Instrumentation API) or JVMTI (Java Virtual Machine Tool Interface, Java Virtual Machine Tool Interface) and other ways.

[0107] Java Instrumentation API: This API (Application Programming Interface) allows developers to write agents that modify bytecode during class loading. This API can be used to insert hook code to monitor and record method-level dependencies.

[0108] JVMTI (Java Virtual Machine Tool Interface): This interface provides access to the internal operations of the Java virtual machine. Through JVMTI, callback functions can be registered, and when specific events occur (such as method compilation, loading, etc.), the Java virtual machine will notify the agent tool.

[0109] In a specific implementation, a Java Agent is designed as an agent tool, and the Java Instrumentation API or JVMTI is used to implement the agent function. This Java Agent can intervene when a class is loaded or a method is compiled. The event (CompiledMethodLoad) is compiled using JVMTI and other methods. Whenever a JIT compiler compiles a method, this event is triggered, and information about the method can be obtained. For each compiled method, its dependencies are analyzed, which includes identifying all other methods directly or indirectly referenced by the method. This can be done by parsing bytecode instructions, because each method call or field access has a corresponding bytecode representation. After determining the dependencies, Hook points are inserted at appropriate locations, which may mean modifying the bytecode so that a predefined tracking function is called each time a dependency is accessed. The task of the tracking function is to record the current dependency status. The obtained dependencies are recorded and stored in a memory data structure, or persisted to a disk file or other form of external storage.

[0110] In some embodiments, the status of all known dependencies is continuously obtained, and if any dependency is found to have changed, the Java virtual machine is immediately notified to recompile the affected method.

[0111] Therefore, the proxy tool can insert a Hook point based on the Inline Hook technology when the just-in-time compiler compiles the method function to obtain the dependency relationship between the various method functions.

[0112] Step S1062: The business process generates the dependency record based on the dependency relationship.

[0113] In this embodiment, the acquired dependency relationship is analyzed, and a dependency record is generated according to the dependency relationship between each method function.

[0114] In some embodiments, the original dependency relationships are organized 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: method function name, other method functions it depends on, dependency type (such as inheritance, interface implementation, method or property usage), and possible circular dependency warnings. In addition, metadata such as version number, license information, etc. can be added to each dependency.

[0115] Step S107: The security tool obtains the Java Agent.

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

[0117] 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.

[0118] 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.

[0119] 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.

[0120] It should be noted that both the proxy tool in step S103 and the Java Agent in step S107 are implemented by JavaAgent. The difference between the two is that the Java Agent of the proxy tool is deployed in advance, and when the application is started, the Java Agent is loaded and enabled, and its function obtains the dependencies at the method function level. The Java Agent whose bytecode is modified by the user is dynamically deployed, allowing different JavaAgents to be introduced as needed at different life cycle stages of the application, and its function obtains the modification of the bytecode.

[0121] Step S108: The security tool modifies the bytecode of the application.

[0122] In this embodiment, the bytecode of the application is modified according to the Java Agent.

[0123] Specifically, Figure 5 1 is a flowchart of bytecode modification in an embodiment of the present invention. Figure 5 As shown, modifying the bytecode of the application according to the JavaAgent includes the following steps:

[0124] Step S1081: The security tool intercepts the original bytecode of the class file of the target class to be loaded.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] Step S1082: The security tool modifies the bytecode of the target class according to the predefined rules or policies in the Java Agent.

[0130] 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.

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

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

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

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

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

[0136] Step S1083: The security tool provides the modified bytecode to the Java virtual machine for loading and execution.

[0137] 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.

[0138] Step S109: perform local deoptimization.

[0139] In this embodiment, local deoptimization is performed based on dependency records.

[0140] Figure 6 1 is a flow chart of local deoptimization in an embodiment of the present invention. Figure 6 As shown, the local deoptimization of the embodiment of the present invention includes the following steps:

[0141] Step S1091: The security tool determines the target method function corresponding to the currently modified bytecode.

[0142] In this embodiment, the modified bytecode in the target class is obtained, and the method function corresponding to the modified bytecode is determined as the target method function.

[0143] Step S1092: The security tool determines the method function that the target method function depends on according to the dependency record.

[0144] In this embodiment, the dependency record includes dependency relationships between various method functions. After the target method function is acquired, the method functions that the target method function depends on are determined according to the dependency record.

[0145] Step S1093: The security tool performs local deoptimization on the currently modified bytecode and dependent method functions.

[0146] In this embodiment, the security tool discards the currently modified bytecode and the local machine code corresponding to the dependent method function to achieve local deoptimization.

[0147] Compared with the statically deployed Java Agent commonly used in the prior art, each Java Agent product needs to be configured separately. Each time a new product is added, the application needs to be reconfigured and restarted, which increases the complexity and cost of operation and maintenance. The embodiment of the present invention adopts a unified pre-suppression Java Agent as an agent tool, provides a unified deoptimization pre-suppression Java Agent, and automatically enables dependency records when the Java process starts. This JavaAgent is compatible with a variety of dynamic bytecode modification tools, and there is no need to configure each Agent product separately.

[0148] At the same time, the static deployment solution relies on class-level deoptimization, which has a general effect and still causes a large number of classes to be recompiled, causing performance jitter. The embodiment of the present invention uses method-level dependency recording and inline hook technology to refine the JVM's dependency record to the method level. In this way, when modifying the bytecode, the JVM can only perform local deoptimization on the affected method, rather than deoptimizing the entire class or the whole world.

[0149] Moreover, some statically deployed Java Agent products are used on demand, which cannot be achieved through static deployment in some special scenarios, such as troubleshooting tool classes, etc. The embodiment of the present invention supports on-demand loading and unloading of JavaAgents, and is applicable to various dynamic usage scenarios, including troubleshooting tools, etc.

[0150] In summary, the embodiment of the present invention uses the pre-suppression Java Agent as an agent tool, but the work content of the pre-suppression Java Agent is not the common bytecode modification, but through Patch JVM (update or patch the Java virtual machine), the dependency record of the JVM is reduced to the granularity of the method (method function) to reduce the deoptimization consumption. That is, the pre-suppression Java Agent obtains the JVM compilation action through Patch JVM to generate a method-level dependency record, so as to reduce the impact range when deoptimization is required to achieve the suppression effect. At the same time, through the pre-suppression Java Agent, the risk of deoptimization in the future due to the need for dynamic injection of Java Agent scenarios for operation and maintenance, security, etc. can be prevented, which is a solution to strengthen stability in advance. Moreover, in addition to enabling dependency records and controlling granularity, the pre-suppression Java Agent will also connect to the deoptimization logic process, and switch to use this optimized dependency record when deoptimization occurs. Moreover, the embodiment of the present invention works at the dependency record and deoptimization link layer, which is transparent to the upper-layer Java Agent, so the compatibility of multiple dynamic bytecode modification tools is achieved.

[0151] The embodiment of the present invention loads and enables the proxy tool when the application is started through the business process, and obtains the dependency record through the proxy tool, the dependency record includes the dependency relationship between each method function, obtains the program Java Agent for modifying the bytecode through the security tool, and performs local deoptimization on the currently modified bytecode and the dependent method function according to the Java Agent and the dependency record. Thus, the dependency relationship at the method function level is obtained based on the proxy tool, the dependency record is generated, and the precise and smaller range of deoptimization is achieved through the dependency record, so as to reduce the negative impact of deoptimization caused by the runtime bytecode modification technology, improve the utilization rate of computing resources, reduce the performance fluctuation of the processor caused by deoptimization, and improve the response speed and stability of the system.

[0152] Figure 7 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:

[0153] Step S210: When the application is started, the business process loads and activates the proxy tool.

[0154] Step S220: The business process obtains a dependency record through the proxy tool, where the dependency record includes dependency relationships between various method functions.

[0155] Step S230: The security tool obtains a Java Agent, where the Java Agent is a program for modifying bytecodes;

[0156] Step S240: The security tool performs local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependency record.

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

[0158] The business process starts a Java virtual machine, which is used to provide an operating environment;

[0159] The service process loads at least one precompiled class file in the Java virtual machine, wherein the class file includes bytecode compiled from Java source code;

[0160] The business process converts the bytecode in the class file into local machine code.

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

[0162] The business process locates the class file according to the given class name and class path;

[0163] The business process reads the class file into memory and parses it into bytecode;

[0164] The business process uses the bytecode to create an object representing the class in the Java virtual machine.

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

[0166] The business process detects the execution of the application and identifies the hot code;

[0167] The service process converts the hotspot code from bytecode to native machine code through a just-in-time compiler.

[0168] In some embodiments, the business process obtaining the dependency record through the proxy tool includes:

[0169] The business process inserts a hook point through the proxy tool based on the inline hook technology when the just-in-time compiler compiles the method function, so as to obtain the dependency relationship between each method function;

[0170] The business process generates the dependency record based on the dependency relationship.

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

[0172] The security tool modifies the bytecode of the application program according to the Java Agent.

[0173] In some embodiments, the security tool modifies the bytecode of the application according to the Java Agent, including:

[0174] The security tool intercepts the original bytecode of the class file of the target class to be loaded;

[0175] The security tool modifies the bytecode of the target class according to the predefined rules or policies in the Java Agent;

[0176] The security tool provides the modified bytecode to the Java virtual machine for loading and execution.

[0177] In some embodiments, the security tool locally deoptimizes the currently modified bytecode and dependent method functions according to the Java Agent and the dependency record, including:

[0178] The security tool determines the target method function corresponding to the currently modified bytecode;

[0179] The security tool determines the method function that the target method function depends on according to the dependency record;

[0180] The security tool performs local deoptimization on the currently modified bytecode and dependent method functions.

[0181] In some embodiments, the security tool locally deoptimizes the currently modified bytecode and dependent method functions, including:

[0182] The security tool discards the currently modified bytecode and the local machine code corresponding to the dependent method function to achieve local deoptimization.

[0183] The embodiment of the present invention loads and enables the proxy tool when the application is started through the business process, and obtains the dependency record through the proxy tool, the dependency record includes the dependency relationship between each method function, obtains the program Java Agent for modifying the bytecode through the security tool, and performs local deoptimization on the currently modified bytecode and the dependent method function according to the Java Agent and the dependency record. Thus, the dependency relationship at the method function level is obtained based on the proxy tool, the dependency record is generated, and the precise and smaller range of deoptimization is achieved through the dependency record, so as to reduce the negative impact of deoptimization caused by the runtime bytecode modification technology, improve the utilization rate of computing resources, reduce the performance fluctuation of the processor caused by deoptimization, and improve the response speed and stability of the system.

[0184] Figure 8 Schematic diagram of a deoptimization control device according to an embodiment of the present invention. Figure 8 As shown, the deoptimization control device of the embodiment of the present invention includes a proxy tool loading unit 81, a dependency record acquisition unit 82, a modification program acquisition unit 83 and a local deoptimization unit 84. Among them, the proxy tool loading unit 81 is used to load and enable the proxy tool when the application starts. The dependency record acquisition unit 82 is used to obtain a dependency record through the proxy tool, and the dependency record includes the dependency relationship between each method function. 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 dependent method functions according to the Java Agent and the dependency record.

[0185] The embodiment of the present invention loads and enables the proxy tool when the application is started through the business process, and obtains the dependency record through the proxy tool, the dependency record includes the dependency relationship between each method function, obtains the program Java Agent for modifying the bytecode through the security tool, and performs local deoptimization on the currently modified bytecode and the dependent method function according to the Java Agent and the dependency record. Thus, the dependency relationship at the method function level is obtained based on the proxy tool, the dependency record is generated, and the precise and smaller range of deoptimization is achieved through the dependency record, so as to reduce the negative impact of deoptimization caused by the runtime bytecode modification technology, improve the utilization rate of computing resources, reduce the performance fluctuation of the processor caused by deoptimization, and improve the response speed and stability of the system.

[0186] 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. 9As 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.

[0187] 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. 9 In 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] The embodiment of the present invention loads and enables the proxy tool when the application is started through the business process, and obtains the dependency record through the proxy tool, the dependency record includes the dependency relationship between each method function, obtains the program Java Agent for modifying the bytecode through the security tool, and performs local deoptimization on the currently modified bytecode and the dependent method function according to the Java Agent and the dependency record. Thus, the dependency relationship at the method function level is obtained based on the proxy tool, the dependency record is generated, and the precise and smaller range of deoptimization is achieved through the dependency record, so as to reduce the negative impact of deoptimization caused by the runtime bytecode modification technology, improve the utilization rate of computing resources, reduce the performance fluctuation of the processor caused by deoptimization, and improve the response speed and stability of the system.

[0192] 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.

[0193] 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.

[0194] 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: The business process loads and enables the proxy tool when the application starts; The business process obtains the dependency record through the proxy tool, and the dependency record includes the dependency relationship between various method functions; The security tool obtains a Java Agent, where the Java Agent is a program for modifying bytecodes; The security tool performs local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependent records.

2. The method according to claim 1, characterized in that The method further comprises: The business process starts a Java virtual machine, which is used to provide an operating environment; The service process loads at least one precompiled class file in the Java virtual machine, wherein the class file includes bytecode compiled from Java source code; The business process converts the bytecode in the class file into local machine code.

3. The method according to claim 2, characterized in that The business process loading at least one precompiled class file in the Java virtual machine includes: The business process locates the class file according to the given class name and class path; The business process reads the class file into memory and parses it into bytecode; The business process uses the bytecode to create an object representing the class in the Java virtual machine.

4. The method according to claim 2, characterized in that: The business process converts the bytecode in the class file into local machine code including: The business process detects the execution of the application and identifies the hot code; The service process converts the hotspot code from bytecode to native machine code through a just-in-time compiler.

5. The method according to claim 4, characterized in that The business process obtains the dependency record through the proxy tool including: The business process inserts a hook point through the proxy tool based on the inline hook technology when the just-in-time compiler compiles the method function, so as to obtain the dependency relationship between each method function; The business process generates the dependency record based on the dependency relationship.

6. The method according to claim 1, characterized in that The method further comprises: The security tool modifies the bytecode of the application program according to the Java Agent.

7. The method according to claim 6, characterized in that The security tool modifies the bytecode of the application according to the Java Agent, including: The security tool intercepts the original bytecode of the class file of the target class to be loaded; The security tool modifies the bytecode of the target class according to the predefined rules or policies in the Java Agent; The security tool provides the modified bytecode to the Java virtual machine for loading and execution.

8. The method according to claim 1, characterized in that The security tool performs local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependent record, including: The security tool determines the target method function corresponding to the currently modified bytecode; The security tool determines the method function that the target method function depends on according to the dependency record; The security tool performs local deoptimization on the currently modified bytecode and dependent method functions.

9. The method according to claim 8, characterized in that The security tool performs local deoptimization on the currently modified bytecode and dependent method functions, including: The security tool discards the currently modified bytecode and the local machine code corresponding to the dependent method function to achieve local deoptimization.

10. A deoptimization control device, characterized in that: The device comprises: The proxy tool loading unit is used to load and enable the proxy tool when the application starts; A dependency record acquisition unit, used to acquire a dependency record through the proxy tool, wherein the dependency record includes dependency relationships between various method functions; A modification program acquisition unit, used to acquire a Java Agent, wherein the Java Agent is a program used to modify bytecodes; The local deoptimization unit is used to perform local deoptimization on the currently modified bytecode and dependent method functions according to the Java Agent and the dependent record.

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