Code hot replacement method and apparatus

Abstract

Provided in the present application are a code hot replacement method and apparatus. The method comprises: acquiring a first bytecode obtained after a source code is compiled, and a second bytecode obtained by means of performing incremental compiling on the modified source code; transferring to a third bytecode the declaration of first-type modified content in modified content in the second bytecode relative to the first bytecode, wherein the first-type modified content comprises modifications other than the modification of a method body; repairing at least one instruction in the second bytecode after transferring is performed or the third bytecode, wherein the at least one instruction is used for calling at least one piece of content in the second bytecode, and the at least one repaired instruction is used for calling the content in the third bytecode that corresponds to the at least one piece of content; and loading a target second bytecode and a target third bytecode. The solution in the embodiments of the present application facilitates the improvement in debugging efficiency.

Description

Method and device for hot code replacement

[0001] This application claims priority to Russian patent application No. 2023115475, filed with the Russian Patent Office on June 14, 2023, entitled “Method and Device for Hot Code Replacement,” the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates to the field of debugging technology, and more specifically, to a method and device for hot code replacement. Background Art

[0003] When software fails to work as expected, users can use debugging tools to analyze the code and determine the cause of the error. Using debugging tools often requires repeatedly stopping and starting the software to modify the code and verify the results. However, some software can take a long time to start, hindering debugging efficiency. For example, large software often has complex layers and multiple components. This often requires launching multiple sub-applications, which takes a long time, significantly increasing time costs and affecting debugging efficiency.

[0004] Related solutions offer some hot code replacement methods, supporting modifications within method bodies. This solution allows modifications to method bodies to be applied instantly without restarting the entire application, saving debugging time. However, this solution only applies to method body modifications and does not support other modification methods.

[0005] Therefore, how to improve debugging efficiency becomes an urgent problem to be solved.

[0006] Summary of the Invention

[0007] The present application provides a method and device for hot code replacement, which is conducive to improving debugging efficiency.

[0008] In a first aspect, a method for hot code replacement is provided, comprising: obtaining a first bytecode and a second bytecode, the first bytecode being the bytecode after source code compilation, and the second bytecode being obtained by incrementally compiling the modified source code; transferring a declaration of a first type of modified content in the modified content relative to the first bytecode in the second bytecode to a third bytecode, the first type of modified content including modified content other than a modified method body; patching at least one instruction in the transferred second bytecode or the third bytecode, the at least one instruction being used to call at least one content in the second bytecode, and the patched at least one instruction being used to call content corresponding to the at least one content in the third bytecode; loading a target second bytecode and a target third bytecode, part or all of the at least one instruction belonging to the transferred second bytecode, the target second bytecode being obtained by patching part or all of at least one instruction in the transferred second bytecode, and in the case where part of the at least one instruction belongs to the third bytecode, the target third bytecode being obtained by patching part of at least one instruction in the third bytecode, or, in the case where at least one instruction does not belong to the third bytecode, the target third bytecode being the third bytecode.

[0009] According to the solution of the embodiment of the present application, the modified content of the code is incrementally compiled to obtain the second bytecode, and the third bytecode is dynamically generated for the second bytecode, or in other words, the third bytecode is generated at runtime, and the target second bytecode and the target third bytecode are loaded to replace the first bytecode, thereby realizing code hot replacement. This is conducive to avoiding repeated full compilation due to code modifications during the debugging process, and is also conducive to avoiding restarting the entire application, thereby saving the time cost of debugging and improving debugging efficiency. In addition, the solution of the embodiment of the present application can reuse the code hot replacement for modifications to the method body, which is conducive to saving costs.

[0010] Exemplarily, the content in the third bytecode corresponding to the content in the second bytecode may be content in the third bytecode with the same name as the content in the second bytecode, for example, the content may be a method.

[0011] Exemplarily, the content in the third bytecode corresponding to the content in the second bytecode may be content in the third bytecode having the same value as the content in the second bytecode. For example, the content may be a field value.

[0012] In combination with the first aspect, in certain implementations of the first aspect, the source code is Java source code, and the first type of modification content includes at least one of the following: an added method, a method with a modified signature, a method with a modifier added, a method with a modifier deleted, an added lambda expression, a lambda expression with a modified body, an added inner anonymous class, or a modified inner anonymous class.

[0013] Exemplarily, modifying the signature of a method includes modifying at least one of the following: a parameter of the method, a type of a parameter of the method, a return value of the method, or a type of a return value of the method.

[0014] Exemplarily, the modifier may include at least one of the following: a “static” modifier or a “synchronized” modifier.

[0015] In combination with the first aspect, in certain implementations of the first aspect, at least one instruction includes a first instruction, at least one content includes a first content, the first content belongs to a first type of modified content, the first instruction is used to call the first content in the second bytecode, and the patched first instruction is used to call the first content in the third bytecode.

[0016] Exemplarily, the first instruction may include a dynamic call instruction or a normal call instruction.

[0017] In the solution of the embodiment of the present application, the relevant calling instructions are patched after the third bytecode is generated, so that the patched instructions can normally call the content transferred to the third bytecode.

[0018] In combination with the first aspect, in certain implementations of the first aspect, at least one instruction includes a second instruction, the second instruction belongs to a third bytecode, at least one content includes a first field value, the second instruction is used to call the first field value in the second bytecode, and patching at least one instruction in the transferred second bytecode or the third bytecode, including: generating a first method and a second method in the third bytecode, the first method is used to access the first field value in the transferred second bytecode through a reflection mechanism, and the second method is used to read the first field value; patching the second instruction so that the patched second instruction is used to call the second method.

[0019] In the solution of the embodiment of the present application, the relevant field value calling instruction is patched after the third bytecode is generated, so that the patched instruction can normally call the member value in the second bytecode.

[0020] In combination with the first aspect, in certain implementations of the first aspect, the first type of modification content includes adding a modifier to a third method or deleting a modifier to a third method, the modifier is a static modifier, the modifier of the third method in the target second bytecode is the same as the modifier of the third method in the first bytecode, and the method body of the third method in the target second bytecode indicates a call to the third method in the third bytecode.

[0021] In combination with the first aspect, in certain implementations of the first aspect, the first type of modified content includes adding a fourth method with a modifier, the modifier being a synchronization modifier, and transferring the declaration of the first type of modified content in the modified content relative to the first bytecode in the second bytecode to the third bytecode includes: transferring the declaration of the asynchronous fourth method to the third bytecode; the modifier of the fourth method in the target second bytecode includes a synchronization modifier, the method body of the fourth method in the target second bytecode indicates calling the synchronized fourth method in the third bytecode, and the synchronized fourth method is implemented based on a synchronization tool.

[0022] In combination with the first aspect, in certain implementations of the first aspect, the first type of modification content includes deleting the modifier of the fifth method, the modifier is a synchronization modifier, the modifier of the fifth method in the target second bytecode does not include the synchronization modifier, and the method body of the fifth method in the target second bytecode indicates a call to the fifth method in the third bytecode.

[0023] In combination with the first aspect, in certain implementations of the first aspect, the first type of modification content includes modifying the signature of the sixth method, the signature of the sixth method in the target second bytecode is the same as the signature of the sixth method in the first bytecode, and the method body of the sixth method in the target second bytecode indicates that an unsupported exception is thrown.

[0024] In combination with the first aspect, in certain implementations of the first aspect, the source code is Java source code, and the instructions in the second type of modified content in the target second bytecode indicate throwing an unsupported exception, and the second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted inner anonymous class.

[0025] For example, in the case where the second bytecode deletes the seventh method relative to the first bytecode, the method further includes: restoring the seventh method in the second bytecode or the second bytecode after the transfer, and modifying the method body of the seventh method so that the modified method body indicates that an unsupported exception is thrown.

[0026] In a second aspect, a device for hot code replacement is provided, comprising: an acquisition module for acquiring a first bytecode and a second bytecode, the first bytecode being the bytecode after source code compilation, and the second bytecode being obtained by incrementally compiling the modified source code; a generation module for transferring a declaration of a first type of modified content in the modified content relative to the first bytecode in the second bytecode to a third bytecode, the first type of modified content including modified content other than a modified method body; a patching module for patching at least one instruction in the transferred second bytecode or the third bytecode, the at least one instruction being respectively used to call at least one content in the second bytecode, and the patched at least one instruction being respectively used to call content corresponding to the at least one content in the third bytecode; a loading module for loading a target second bytecode and a target third bytecode, part or all of the at least one instruction belonging to the transferred second bytecode, the target second bytecode being obtained by patching part or all of at least one instruction in the modified second bytecode, and in the case where part of the at least one instruction belongs to the third bytecode, the target third bytecode being obtained by patching part of at least one instruction in the third bytecode, or, in the case where at least one instruction does not belong to the third bytecode, the target third bytecode being the third bytecode.

[0027] In combination with the second aspect, in certain implementations of the second aspect, the source code is Java source code, and the first type of modification content includes at least one of the following: an added method, a method with a modified signature, a method with a modifier added, a method with a modifier deleted, an added lambda expression, a lambda expression with a modified body, an added inner anonymous class, or a modified inner anonymous class.

[0028] In combination with the second aspect, in certain implementations of the second aspect, at least one instruction includes a first instruction, at least one content includes a first content, the first content belongs to a first type of modified content, the first instruction is used to call the first content in the second bytecode, and the patched first instruction is used to call the first content in the third bytecode.

[0029] In combination with the second aspect, in certain implementations of the second aspect, at least one instruction includes a second instruction, the second instruction belongs to a third bytecode, at least one content includes a first field value, the second instruction is used to call the first field value in the second bytecode, and the patching module is specifically used to: generate a first method and a second method in the third bytecode, the first method is used to access the first field value in the transferred second bytecode through a reflection mechanism, and the second method is used to read the first field value; and patch the second instruction so that the patched second instruction is used to call the second method.

[0030] In combination with the second aspect, in certain implementations of the second aspect, the first type of modification content includes adding a modifier to the third method or deleting the modifier to the third method, the modifier is a static modifier, the modifier of the third method in the target second bytecode is the same as the modifier of the third method in the first bytecode, and the method body of the third method in the target second bytecode indicates a call to the third method in the third bytecode.

[0031] In combination with the second aspect, in certain implementations of the second aspect, the first type of modification content includes adding a modifier to the fourth method, the modifier is a synchronization modifier, and the generation module is specifically used to: transfer the declaration of the non-synchronized fourth method to the third bytecode; the modifier of the fourth method in the target second bytecode includes a synchronization modifier, the method body of the fourth method in the target second bytecode indicates a call to the synchronized fourth method in the third bytecode, and the synchronized fourth method is implemented based on a synchronization tool.

[0032] In combination with the second aspect, in certain implementations of the second aspect, the first type of modification content includes deleting the modifier of the fifth method, the modifier is a synchronization modifier, the modifier of the fifth method in the target second bytecode does not include the synchronization modifier, and the method body of the fifth method in the target second bytecode indicates a call to the fifth method in the third bytecode.

[0033] In combination with the second aspect, in certain implementations of the second aspect, the first type of modification content includes modifying the signature of the sixth method, the signature of the sixth method in the target second bytecode is the same as the signature of the sixth method in the first bytecode, and the method body of the sixth method in the target second bytecode indicates that an unsupported exception is thrown.

[0034] In combination with the second aspect, in certain implementations of the second aspect, the source code is Java source code, and the instructions in the second type of modified content in the target second bytecode indicate throwing an unsupported exception, and the second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted inner anonymous class.

[0035] It should be understood that the expansion, limitation, explanation and description of the relevant content in the above-mentioned first aspect also apply to the same content in the second aspect.

[0036] In a third aspect, a computing device cluster is provided, comprising at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method of the first aspect and any implementation of the first aspect.

[0037] In a fourth aspect, a computer-readable medium is provided, comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method in the first aspect and any one of the implementations of the first aspect.

[0038] In a fifth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the method in the above-mentioned first aspect and any one of the implementations of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] FIG1 is a schematic flow chart of a method for hot code replacement according to an embodiment of the present application;

[0040] FIG2 is a schematic diagram of the relationship between three types of embodiments of the present application;

[0041] FIG3 is a schematic diagram of a partial process of code hot replacement according to an embodiment of the present application;

[0042] FIG4 is a schematic diagram of a satellite class loading process according to an embodiment of the present application;

[0043] FIG5 is a schematic block diagram of a device for hot code replacement according to an embodiment of the present application;

[0044] FIG6 is a schematic block diagram of a computing device according to an embodiment of the present application;

[0045] FIG7 is a schematic block diagram of a computing device cluster according to an embodiment of the present application;

[0046] FIG8 is a schematic block diagram of another computing device cluster according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] The technical solution in this application will be described below with reference to the accompanying drawings.

[0048] In order to help those skilled in the art better understand the technical solutions of the present application, some terms that may be involved in the embodiments of the present application are explained below.

[0049] 1. Integrated development environment (IDE):

[0050] IDE is an application used to provide a program development environment, generally including tools such as code editors, compilers, debuggers, and graphical user interfaces. It is an integrated development software service suite that integrates code writing, analysis, compilation, debugging, and other functions.

[0051] IDEs can include local IDEs and web IDEs. A local IDE can also be called a desktop IDE. A local IDE is installed in the user's local development operating environment. For example, the local development operating environment can be a terminal device, such as a desktop computer, laptop, or mobile phone. A web IDE refers to an online IDE service that includes an IDE front-end and an IDE back-end. The IDE back-end runs in a remote environment. For example, the remote environment can be a cloud server.

[0052] (2) Hot code replace (HCR):

[0053] HCR refers to modifying the program code while the application is running and applying the changes immediately without restarting the application. Taking Java applications as an example, HCR refers to updating Java class files while the application is running.

[0054] Computer programming is an abstract, conceptual activity that uses programming languages ​​to abstract data and information so that users can effectively interact with the computer. Multiple abstraction layers and components within a software program communicate to make the program work properly. If a software program does not work as expected, it is necessary to analyze the code to determine the cause of the error. Debugging is the process of finding and fixing errors in the source code of a software program. Large software programs, such as most server-side applications, are based on complex programming frameworks with complex layers and numerous components. When errors occur, locating and resolving the underlying issues can be challenging.

[0055] Debugging tools allow users to run software programs in a controlled environment, step through the code, and analyze and fix problems. Debugging with debugging tools helps resolve problems faster and improves user productivity.

[0056] The performance of debugging tools significantly impacts the quality of software programs and the user experience. Debugging with debugging tools often requires repeatedly stopping and restarting the running program to modify code and verify results. Large software programs often require launching multiple sub-applications, which is time-consuming. This repeated restart and shutdown can significantly impact debugging efficiency.

[0057] Related solutions offer some hot code replacement methods, leveraging the standard Java virtual machine (JVM)'s hot swapping capabilities to instantly apply modifications within method bodies without restarting the entire application. However, these solutions only work with method body modifications and do not support other modification methods, making their functionality quite limited.

[0058] In view of this, an embodiment of the present application provides a method for hot code replacement, which supports hot replacement of complex code modifications and is conducive to improving debugging efficiency.

[0059] FIG1 shows a schematic diagram of a method for hot code replacement according to an embodiment of the present application.

[0060] As shown in FIG1 , method 100 includes the following steps.

[0061] 101. Obtain bytecode #1 (an example of the first bytecode) and bytecode #2 (an example of the second bytecode). Bytecode #1 is the bytecode compiled from the source code before modification, and bytecode #2 is obtained by incrementally compiling the modified source code.

[0062] The source code before modification can also be called the original code. Bytecode #1 can also be called the original bytecode.

[0063] 102. The declaration of the first type of modification content in the modification content of bytecode #2 relative to bytecode #1 is transferred to bytecode #3 (an example of the third bytecode).

[0064] The first type of modification content includes modifications other than modifications to the method body.

[0065] A method can also be called a function. The method body within a method can also be called a function body.

[0066] 103. Patch at least one instruction. The at least one instruction belongs to bytecode #3 or the transferred bytecode #2. The at least one instruction is used to call at least one content in bytecode #2. The patched at least one instruction is used to call content in bytecode #3 corresponding to the at least one content in bytecode #2.

[0067] The at least one instruction may be referred to as an instruction to be patched. The instruction to be patched may be located in bytecode #2 or bytecode #3 after the transfer. That is, the at least one instruction may belong to the same bytecode file or different bytecode files.

[0068] For example, the at least one instruction may be entirely located in the transferred bytecode #2. For another example, the at least one instruction may include multiple instructions to be patched, a portion of the multiple instructions to be patched being located in the transferred bytecode #2 and another portion being located in the bytecode #3.

[0069] As a possible example, the content in bytecode #3 corresponding to the content in bytecode #2 may be content in bytecode #3 with the same name as the content in bytecode #2. For example, the content may be a method.

[0070] Illustratively, the at least one instruction includes instruction #1 (an example of a first instruction). Instruction #1 is used to call method #B in bytecode #2. The patched instruction #1 is used to call method #B in bytecode #3. Method #B in bytecode #3 has the same name as method #B in bytecode #2.

[0071] As a possible example, the content in bytecode #3 that corresponds to the content in bytecode #2 may be content in bytecode #3 that has the same value as the content in bytecode #2. For example, the content may be a field value.

[0072] Illustratively, the at least one instruction includes instruction #2 (an example of a second instruction). Instruction #2 is used to call field value #A in bytecode #2. The patched instruction #2 is used to call field value #A in bytecode #3. Field value #A in bytecode #3 is the same as field value #A in bytecode #2.

[0073] The detailed description of step 103 can be found in the following text and will not be expanded here.

[0074] 104, load target bytecode #3 (an example of the target third bytecode) and target bytecode #2 (an example of the target second bytecode).

[0075] Part or all of the at least one instruction belongs to the transferred bytecode #2. The target bytecode #2 is obtained by patching part or all of the at least one instruction in the transferred bytecode #2.

[0076] If the at least one instruction does not belong to bytecode #3, target bytecode #3 is bytecode #3. Alternatively, if a portion of the at least one instruction belongs to bytecode #3, target bytecode #3 is obtained by patching a portion of the at least one instruction in bytecode #3.

[0077] In one example, all of the at least one instruction belong to the transferred bytecode #2. The at least one instruction in the transferred bytecode #2 is patched, and the resulting bytecode file after the patching is the target bytecode #2. The instructions in bytecode #3 do not need to be patched, and the target bytecode #3 is bytecode #3.

[0078] In another example, a portion (portion #A) of the at least one instruction belongs to the transferred bytecode #2, and another portion (portion #B) belongs to bytecode #3. Portion #A of the transferred bytecode #2 is patched, and the resulting bytecode file after the patching is target bytecode #2. Portion #B of bytecode #3 is patched, and the resulting bytecode file after the patching is target bytecode #3.

[0079] In the embodiment of the present application, method 100 can be executed by a debugger. Bytecode #3 is generated while the debugger is running, or in other words, bytecode #3 is dynamically generated. In other words, during the execution of method 100, there is no need to stop the debugger. The debuggee is set to a paused state by the debugger and can be switched to a running state at any time. The debuggee is the target program. The modified source code belongs to the source code of the target program.

[0080] The method of the embodiment of the present application can be applied to multiple programming languages, such as Java or Python.

[0081] When the solution of the embodiment of the present application is applied to Python, the source code can be a .py file. The bytecode can be a .pyc file. The bytecode can also be called module bytecode or module bytecode file. Bytecode #1 can be called the original module, bytecode #2 can be called the new module, and bytecode #3 can be called the satellite module.

[0082] When the solution of the embodiment of the present application is applied to Java, the source code can be a .java file. The bytecode can be a .class file. The bytecode can also be called a class bytecode, a class bytecode file, or a class file. A method is a method in a class or a function in a class. Bytecode #1 can be called the original class bytecode or the original class, bytecode #2 can be called the new class bytecode or the new class, and bytecode #3 can be called the satellite class bytecode or the satellite class. For ease of description, the embodiments of the present application are mainly described using Java programs as an example, and the solution of the embodiments of the present application is not limited thereto.

[0083] FIG2 is a schematic diagram illustrating the relationship between bytecodes provided by an embodiment of the present application. Taking method 100 applied to Java as an example, the bytecode corresponding to the original code is the original class. As shown in FIG2 , the original class is modified into a new class. Specifically, the user modifies the original code. Incremental compilation of the modifications yields the bytecode for the new class. Satellite classes are dynamically generated for the new class. The relationship between the satellite class and the new class is a code call relationship.

[0084] Optionally, the source code may be Java source code, and the first type of modification content may include at least one of the following: an added method, a method with a modified signature, a method with added modifiers, a method with deleted modifiers, an added lambda expression, a modified body lambda expression, an added inner anonymous class, or a modified inner anonymous class.

[0085] It should be understood that the above are merely examples, and the first type of modification content may also include other modifications.

[0086] Alternatively, the source code may be Java source code, and the instruction in the second type of modified content in the target second bytecode instructs throwing an unsupported exception. The second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted inner anonymous class. A lambda expression, also known as a lambda, is an anonymous function, i.e., a function without a function name.

[0087] For example, bytecode #3 may include all first-type modifications to bytecode #1.

[0088] For example, the first type of modification content may include "incompatible" code changes to bytecode #1. "Incompatible" code changes refer to code changes that do not meet the requirements of the standard JVM hotswap. Correspondingly, "compatible" code changes refer to code changes that meet the requirements of the standard JVM hotswap, that is, modifications to method bodies.

[0089] Thus, bytecode #3 may include all "incompatible" code changes to bytecode #1.

[0090] Exemplarily, modifying the signature of a method includes modifying at least one of the following: a parameter of the method, a type of a parameter of the method, a return value of the method, or a type of a return value of the method.

[0091] Exemplarily, the modifier may include at least one of the following: a “static” modifier or a “synchronized” modifier.

[0092] Step 102 is described below.

[0093] Step 102 can be understood as follows: Bytecode #3 is generated based on the first type of modifications in bytecode #2 relative to bytecode #1, and bytecode #2 is modified so that the transferred bytecode #2 does not include a declaration identical to the method declaration in bytecode #3.

[0094] The first type of modification content in bytecode #2 relative to bytecode #1 corresponds to the first type of modification content in the modification of the source code. That is, bytecode #3 corresponds to the first type of modification content in the modification of the source code.

[0095] In step 102 , an empty bytecode file may be created, and the declaration of the first type of modified content in bytecode # 2 may be moved to the bytecode file to obtain bytecode # 3 .

[0096] For ease of description, the following mainly uses methods as an example. For the processing methods of adding or modifying lambda expressions or adding or modifying internal anonymous classes, please refer to the processing methods of methods.

[0097] Illustratively, the first type of modified content includes method #1 added by bytecode #2 relative to bytecode #1.

[0098] In other words, method #1 in bytecode #2 does not belong to bytecode #1. Bytecode #1 does not include method #1, that is, bytecode #1 does not include a method with the same name as method #1.

[0099] Illustratively, the first type of modification content includes method #2 (an example of the sixth method) in which bytecode #2 modifies the signature relative to bytecode #1.

[0100] Method #2 in bytecode #2 can be obtained by modifying the signature of method #2 in bytecode #1.

[0101] If the signature of method #A in bytecode #2 changes from that of method #A in bytecode #1, then method #A in bytecode #2 is considered method #2 in bytecode #2. Method #A in bytecode #2 has the same name as method #A in bytecode #1. In step 102, the declaration of method #A in bytecode #2 is moved to bytecode #3.

[0102] Illustratively, the first type of modification content includes method #3 (an example of the third method) in which bytecode #2 adds a static modifier or deletes a static modifier relative to bytecode #1.

[0103] Method #3 in bytecode #2 can be obtained by removing the static modifier from method #3 in bytecode #1. Alternatively, method #3 in bytecode #2 can be obtained by adding the static modifier to method #3 in bytecode #1.

[0104] If the static modifier is added or removed from method #C in bytecode #2, then method #C in bytecode #2 can be considered method #3 in bytecode #2. Method #C in bytecode #2 has the same name as method #C in bytecode #1. In step 102, the declaration of method #C in bytecode #2 is moved to bytecode #3.

[0105] Illustratively, the first type of modification content includes method #4 (an example of the fourth method) in which bytecode #2 adds a synchronization modifier relative to bytecode #1.

[0106] Method #4 in bytecode #2 can be obtained by adding the synchronized modifier to method #4 in bytecode #1.

[0107] If the synchronized modifier is added to method #D in bytecode #2 relative to method #D in bytecode #1, method #D in bytecode #2 can be treated as method #4 in bytecode #2. Method #D in bytecode #2 has the same name as method #D in bytecode #1. In step 102, the declaration of method #D is moved to bytecode #3.

[0108] Illustratively, the first type of modification content includes method #5 (an example of the fifth method) in which bytecode #2 deletes the synchronization modifier relative to bytecode #1.

[0109] Method #5 in bytecode #2 can be obtained by removing the synchronized modifier from method #5 in bytecode #1.

[0110] If the synchronized modifier is removed from method #E in bytecode #2 relative to method #E in bytecode #1, method #E in bytecode #2 can be treated as method #5 in bytecode #2. Method #E in bytecode #2 has the same name as method #E in bytecode #1. In step 102, the declaration of method #E is moved to bytecode #3.

[0111] In the embodiments of the present application, the first type of modified content can all be referred to as "special methods", for example, methods added to bytecode #2 relative to bytecode #1, and methods in bytecode #2 whose signatures and / or modifiers have changed relative to bytecode #1. Methods #1 to #5 are special methods. The processing methods for other special methods can refer to methods #1 to #5. For ease of description, the embodiments of the present application are mainly explained by taking methods #1 to #5 as examples, and do not limit the solutions of the embodiments of the present application.

[0112] In step 102 , declarations of all special methods may be transferred from bytecode # 2 to bytecode # 3 .

[0113] Taking the application of method 100 to a Java program as an example, in step 102, an empty satellite class can be defined, and the declaration of the special method can be moved from the new class to the empty satellite class, thereby generating a satellite class, i.e., a satellite class bytecode, as shown in FIG3 .

[0114] As described above, the instruction in the second type of modified content in the target second bytecode indicates that an unsupported exception is thrown.

[0115] Taking the second type of modification content including deletion of the method as an example, for example, the second type of modification content includes deletion of method #6, method 100 may also include: restoring method #6 in bytecode #2; modifying the method body of method #6 so that the modified method body of method #6 indicates that an unsupported exception is thrown.

[0116] In the case that bytecode #2 deletes a method relative to bytecode #1, the method can be restored in bytecode #2, and the method body of the method can be modified so that the modified method body indicates that an unsupported exception is thrown.

[0117] Furthermore, in the case that bytecode #2 adds or deletes a static modifier to a method in bytecode #1, method 100 also includes: restoring the method in bytecode #1 in bytecode #2, and modifying the method body of the method so that the modified method body indicates a call to the method in bytecode #3.

[0118] In other words, when adding or removing the static modifier to a method, the declaration of the method in bytecode #2 can be transferred to bytecode #3, and the method in bytecode #1 can be added to bytecode #2, and the method body of the method can be modified to call the method in bytecode #3, that is, the added method in bytecode #1 calls the method in bytecode #3.

[0119] Optionally, taking method #3 as an example, target bytecode #2 includes method #3, the modifier of method #3 in target bytecode #2 is the same as the modifier of method #3 in bytecode #1, and the method body of method #3 in target bytecode #2 indicates calling method #3 in bytecode #3.

[0120] The modifiers of method #3 in target bytecode #2 are the same as the modifiers of method #3 in bytecode #1, meaning that if method #3 in bytecode #1 includes the static modifier, then method #3 in target bytecode #2 also includes the static modifier; or if method #3 in bytecode #1 does not include the static modifier, then method #3 in target bytecode #2 also does not include the static modifier.

[0121] Exemplarily, the method 100 may further include: restoring the method #3 in the bytecode #1 in the bytecode #2; and modifying the method body of the restored method #3 so that the modified method body of the method #3 indicates calling the method #3 in the bytecode #3.

[0122] For ease of description, method #3 in bytecode #1 is referred to as method #3-a, and method #3 in bytecode #2 is referred to as method #3-b. Method #3 in the source code is modified, that is, method #3-a in the source code is changed to method #3-b.

[0123] For example, remove the static modifier from method #3 in the source code. For another example, add a static modifier to method #3 in the source code. Incrementally compile the modified source code to generate bytecode #2. If method #3-b in bytecode #2 has a static modifier added or removed relative to method #3-a in bytecode #1, then the declaration of method #3-b in bytecode #2 can be transferred to bytecode #3, and method #3-a in bytecode #1 can be restored in bytecode #2. The method body of the restored method #3-a can be modified to call method #3-b in bytecode #3.

[0124] Furthermore, when the signature of a method in bytecode #2 changes relative to that in bytecode #1, the method 100 may also include: restoring the method in bytecode #1 in bytecode #2, and modifying the method body of the method so that the modified method body indicates that an unsupported exception is thrown.

[0125] In other words, when the signature of a method changes, the declaration of the method in bytecode #2 can be transferred to bytecode #3, and the method in bytecode #1 can be added to bytecode #2, and the method body of the method can be modified to throw an unsupported exception.

[0126] Optionally, taking method #2 as an example, target bytecode #2 includes method #2, the signature of method #2 in target bytecode #2 is the same as the signature of method #2 in bytecode #1, and the method body of method #2 in target bytecode #2 indicates that an unsupported exception is thrown.

[0127] Exemplarily, when the difference between method #2 in bytecode #2 and method #2 in bytecode #1 includes a signature, the method further includes: restoring method #2 in bytecode #1 in bytecode #2; and modifying the method body of the restored method #2 so that the method body of the modified method #2 indicates that an unsupported exception is thrown.

[0128] For ease of description, method #2 in bytecode #1 is referred to as method #2-a, and method #2 in bytecode #2 is referred to as method #2-b. The signature of method #2 in the source code is modified, that is, method #2-a in the source code is changed to method #2-b.

[0129] Incrementally compile the modified source code to generate bytecode #2. If the signature of method #2-b in bytecode #2 has changed relative to the signature of method #2-a in bytecode #1, the declaration of method #2-b in bytecode #2 can be moved to bytecode #3, and method #2-a in bytecode #1 can be restored in bytecode #2. The method body of the restored method #2-a can be modified to throw an unsupported exception.

[0130] Furthermore, if bytecode #2 adds a synchronized modifier to a method in bytecode #1, step 102 may include: moving the declaration of the non-synchronized method to bytecode #3, thereby synchronizing the method based on the synchronization mechanism. Method 100 may also include: modifying the method body of the synchronized method in bytecode #2 so that the modified method body indicates a call to the synchronized method in bytecode #3.

[0131] Alternatively, taking method #4 as an example, step 103 may include moving the declaration of the non-synchronized method #4 to bytecode #3. Target bytecode #2 includes method #4, the modifier of method #4 in target bytecode #2 includes a synchronized modifier, and the method body of method #4 in target bytecode #2 indicates a call to synchronized method #4 in bytecode #3. The synchronized method #4 in bytecode #3 is implemented using a synchronization tool.

[0132] For example, the synchronization tool may be a monitor mechanism.

[0133] For example, if a synchronized modifier is added to method #4 in bytecode #2 relative to method #4 in bytecode #1, in step 102, non-synchronized method #4 can be treated as an added method, defined in bytecode #3, and wrapped with a synchronization tool to obtain synchronized method #4. Synchronized method #4 is retained in bytecode #2, and the method body of synchronized method #4 in bytecode #2 is modified so that the method body of method #4 in bytecode #2 indicates a call to synchronized method #4 in bytecode #3.

[0134] Furthermore, if bytecode #2 removes the synchronized modifier from a method in bytecode #1, step 102 may include: moving the declaration of the non-synchronized method in bytecode #2 to bytecode #3. The method 100 may also include: modifying the method body of the non-synchronized method in bytecode #2 so that the modified method body indicates a call to the non-synchronized method in bytecode #3.

[0135] Optionally, taking method #5 as an example, target bytecode #2 includes method #5, the modifier of method #5 in target bytecode #2 does not include a synchronization modifier, and the method body of method #5 in target bytecode #2 indicates calling the non-synchronized method #5 in bytecode #3.

[0136] For example, if the synchronized modifier is removed from method #5 in bytecode #2 relative to method #5 in bytecode #1, in step 102, the unsynchronized method #5 is treated as an added method and defined in bytecode #3. The unsynchronized method #5 is retained in bytecode #2, and the method body of the unsynchronized method #5 is modified so that the method body of the method #5 in bytecode #2 indicates a call to the unsynchronized method #5 in bytecode #3.

[0137] Step 103 is described below.

[0138] Optionally, the at least one instruction includes instruction #1, the at least one content includes content #1 (an example of the first content), content #1 belongs to the first type of modified content, instruction #1 is used to call content #1 in bytecode #2, and the patched instruction #1 is used to call content #1 in bytecode #3.

[0139] In step 103, instructions in the transferred bytecode #2 and / or bytecode #3 are patched so that the patched instructions call the content in bytecode #3.

[0140] If the instruction to be patched is located in a method body, step 103 may be understood as patching the method body in the transferred bytecode #2 and / or the method body in the bytecode #3.

[0141] One or more methods in bytecode #2 may need to call a "special method," and the relevant call instructions indicate the call of the "special method" in bytecode #2. After step 102, the declaration of the "special method" has been transferred to bytecode #3. At this point, the relevant call instructions cannot properly call the "special method." In this case, the relevant call instructions can be patched so that the patched relevant call instructions indicate the call of the "special method" in bytecode #3. This relevant call instruction is at least one instruction in step 103.

[0142] In a possible implementation, the content called by the instruction to be patched may include a method, that is, the instruction to be patched may be a calling instruction of the method.

[0143] The following description will be made using method #7 as an example of content #1. It should be understood that this description only uses method #7 as an example, and the patching methods for calling instructions of other special methods can refer to the patching methods for calling instructions of method #7.

[0144] Optionally, the at least one instruction includes instruction #1, instruction #1 is used to call method #7 in bytecode #2, and the patched instruction #1 is used to call method #7 in bytecode #3.

[0145] One or more methods in bytecode #2 may need to call method #7. For example, instruction #1 instructs to call method #7 in bytecode #2. After step 102, the declaration of method #7 has been transferred to bytecode #3. At this point, instruction #1 cannot properly call method #7. In step 103, instruction #1 can be patched so that the patched instruction #1 calls method #7 in bytecode #3.

[0146] Taking the application of method 100 to a Java program as an example, the patching of instruction #1 may be to change the class to which method #7 in instruction #1 belongs from a new class to a satellite class.

[0147] As a possible example, instruction #1 is located in bytecode #2 after the transfer. Exemplarily, instruction #1 may include a normal call instruction or a dynamic call instruction. For example, instruction #1 may be a dynamic call instruction for method #7, i.e., INVOKEDYNAMIC. For another example, instruction #1 may be a normal call instruction for method #7.

[0148] In other words, the calling instruction to the “special method” in bytecode #2 may include a normal calling instruction or a dynamic calling instruction.

[0149] For example, in step 103, all method bodies in the transferred bytecode #2 may be scanned, and the call instructions for the "special method" may be patched. The instructions for calling the "special method" in bytecode #2 may be patched to instructions for calling the "special method" in bytecode #3. The call instructions for the "special method" may include normal call instructions for the "special method" and dynamic call instructions for the "special method".

[0150] As a possible example, instruction #1 is located in bytecode #3. That is, instruction #1 in bytecode #3 is used to call method #7 in bytecode #2. Exemplarily, instruction #1 can be a virtual method call instruction, namely, INVOKEVIRTUAL.

[0151] For example, in step 103, all method bodies in bytecode #3 can be scanned, and the calling instructions of the "special method" can be patched, and the instructions for calling the "special method" in bytecode #2 can be patched to instructions for calling the "special method" in bytecode #3.

[0152] Furthermore, the method in bytecode #3 is a static method, and the patched instruction #1 may be used to call static method #7 in bytecode #3.

[0153] In another possible implementation, the content of the instruction call to be patched may be a field value, that is, the instruction to be patched may be an instruction related to the field value. For example, the instruction to be patched may include one or more of an instruction for getting a field value or an instruction for setting a field value. For example, the instruction to be patched may include getfield() or putfield().

[0154] After step 102, the declaration of the "special method" has been transferred to bytecode #3. Bytecode #3 may contain one or more methods that access field values ​​in the transferred bytecode #2. Specifically, the relevant instructions instruct to call the field values ​​in the transferred bytecode #2. In this case, the relevant instructions cannot normally access these field values. In this case, the relevant instructions can be patched so that they instruct to call the field values ​​in bytecode #3.

[0155] The following description will be made by taking as an example the case where at least one content includes a field value #1 (an example of a first field value).

[0156] The at least one instruction includes instruction #2, and the content called by instruction #2 may include field value #1. For example, instruction #2 may be used to obtain field value #1 or set field value #1.

[0157] Optionally, instruction #2 belongs to bytecode #3, and instruction #2 is used to obtain field value #1 of bytecode #2 after transfer. Step 103 may include: generating method #8 (an example of the first method) and method #9 (an example of the second method) in bytecode #3, method #8 is used to call field value #1 of bytecode #2 after transfer through the reflection mechanism, and method #9 is used to read the field value #1; patching instruction #2, and the patched instruction #2 is used to call method #9.

[0158] Instruction #2 was originally used to call the field value of bytecode #2 (or bytecode #2 after the transfer). In step 102, the declaration of the "special method" is transferred to bytecode #3, and instruction #2 can be an instruction in the "special method". In this case, instruction #2 is transferred to bytecode #3. At this time, instruction #2 may not be able to implement normal calls to members of bytecode #2. In step 103, an auxiliary accessor can be generated to read the member value. The auxiliary accessor includes method #8 and method #9. At the same time, instruction #2 is patched so that the patched instruction #2 can call method #9, so that the field value of bytecode #2 can be accessed.

[0159] According to the solution of the embodiment of the present application, the modified content of the code is incrementally compiled to obtain bytecode #2, and bytecode #3 is dynamically generated for bytecode #2, or in other words, bytecode #3 is generated at runtime, realizing code hot replacement. This helps to avoid repeated full compilation due to code modifications during the debugging process, and also helps to avoid restarting the entire application, thereby saving debugging time and improving debugging efficiency. The solution of the embodiment of the present application can reuse the code hot replacement for method body modifications in the existing solution, which helps to save costs.

[0160] FIG3 is a schematic diagram showing a partial process of code hot replacement according to an embodiment of the present application.

[0161] As shown in FIG3 , the method 100 may be executed by a device for hot code replacement (ie, the HCR device in FIG3 ).

[0162] The input of the HCR device includes the original class bytecode and the new class bytecode, and the output of the HCR device includes the target new class bytecode and the target satellite class bytecode.

[0163] The original class bytecode corresponds to bytecode #1 in method 100. The new class bytecode corresponds to bytecode #2 in method 100.

[0164] The target new class bytecode corresponds to target bytecode #2 in method 100. The target satellite class bytecode corresponds to target bytecode #3 in method 100.

[0165] Specifically, the new class bytecode in FIG3 is obtained by incrementally compiling the modified source code, or in other words, by incrementally compiling the modifications to the original class.

[0166] The target new class bytecode corresponds to a compatible code modification, i.e., a code modification that satisfies the JVM hotswap requirements, i.e., a code modification that only modifies the method body.

[0167] The target satellite class bytecode corresponds to an incompatible code modification, that is, a code modification that does not meet the JVM hotswap requirements. For example, the target satellite class bytecode corresponds to a code modification that adds a method or modifies a method signature.

[0168] The HCR device can perform the following steps.

[0169] S1, detects modifications in the new class bytecode that are incompatible with JVM hotswap to obtain "special methods".

[0170] After obtaining the original class bytecode and the new class bytecode, code modifications in the new class bytecode that do not meet the JVM hotswap requirements, that is, code changes that are incompatible with JVM hotswap, can be detected to obtain a list of "special methods".

[0171] "Special methods" include at least one of the following: added methods, methods with modified signatures, methods with added modifiers, or methods with removed modifiers, etc.

[0172] S2, moves the declaration of the "special method" in the new class bytecode to the satellite class, thereby generating the satellite class bytecode.

[0173] Define an empty satellite class and move the declaration of "special methods" to the satellite class, thereby generating satellite class bytecode.

[0174] The satellite class bytecode corresponds to bytecode #3 in method 100. The new class bytecode after moving the declaration of the "special method" in the new class bytecode to the satellite class (referred to as the "modified new class bytecode") corresponds to the transferred bytecode #2 in method 100.

[0175] S3, scans the method body in the new class bytecode and patches the relevant instructions.

[0176] Exemplarily, scanning the method body in the new class bytecode may include scanning the method body in the modified new class bytecode and the method body in the satellite class bytecode.

[0177] If there is an instruction to be patched in the satellite bytecode, it is patched to obtain the target satellite bytecode. If there is no instruction to be patched in the satellite bytecode, the satellite bytecode is the target satellite bytecode.

[0178] Exemplarily, the relevant instructions may include the following four types.

[0179] Type 1: Ordinary call to a special method by the new class.

[0180] That is, type 1 refers to a normal call instruction located in the modified new class bytecode, and the normal call instruction is used to implement a normal call to a special method.

[0181] Type 2: Dynamic call of special methods by new classes.

[0182] That is, type 2 refers to a dynamic call instruction located in the modified new class bytecode, which is used to implement dynamic calling of a special method.

[0183] Type 3: The calling method of the field value.

[0184] That is, type 3 refers to instructions related to field values, such as get instructions or set instructions. The get instruction is used to obtain the field value. The set instruction is used to set the field value.

[0185] Type 4: The satellite class calls the method of the new class.

[0186] That is, type 4 refers to a call instruction located in the satellite class bytecode. This call instruction is used to call a method of the new class.

[0187] Specifically, the call instruction is used to indicate the call to the "special method" of the new class.

[0188] After patching the instructions, the target satellite class bytecode and the target new class bytecode can be obtained.

[0189] The target satellite class bytecode and the target new class bytecode can be dynamically loaded into the JVM of the debuggee.

[0190] In the solution of the embodiment of the present application, satellite classes can be generated when the JVM is running.

[0191] It should be noted that the step numbers in FIG3 are only for convenience of description and do not limit the execution order of the steps.

[0192] It should be understood that FIG3 only illustrates the application of the solution of the embodiment of the present application to the Java scenario as an example, and does not limit the application scenario of the solution of the embodiment of the present application.

[0193] Figure 4 shows a schematic diagram of a satellite class loading process. Exemplarily, the HCR device can be used as a module of an IDE debugger.

[0194] As shown in FIG4 , the loading process may include the following steps.

[0195] S41: The IDE debugger obtains a request for hot code replacement, which may include the original class bytecode and the new class bytecode.

[0196] S42, the IDE debugger searches for the original class in the JVM of the debuggee.

[0197] S43: The IDE debugger obtains the class loader (CL) of the original class and the handle of the defineclass method of the original class. The defineclass method of the original class can be represented as CL.defineclass().

[0198] S44, the IDE debugger writes the target satellite class bytecode into the bytecode cache of the JVM of the debugged object.

[0199] In addition, the IDE debugger can write the target new class bytecode into the bytecode cache of the JVM of the debugged object to subsequently replace the original class bytecode.

[0200] S45, the IDE debugger calls CL.defineclass() to create and load the satellite class in the JVM of the debugged object, that is, to implement the definition and loading of the satellite class.

[0201] The following examples illustrate step 102 and step 103 with reference to Examples 1 to 5. Bytecodes include instructions represented by binary. To more intuitively describe the embodiments of the present application, bytecodes are represented in a readable manner in the examples.

[0202] Example 1:

[0203] In Example 1, the modification includes adding a method. The following example illustrates this.

[0204] The original class bytecode includes:

[0205] "public" is a modifier. "HotReplaceProbe" is the class name. "private" is a modifier, indicating private access, meaning only the class can access it directly. "final" is a modifier. "counter" indicates a counter. "buffer" indicates a cache. "L" indicates an array type. "probe()" is the method name. "LDC" is a constant push instruction. "ARETURN" is a method return instruction.

[0206] New bytecode classes include:

[0207] "ALOAD" is a local variable push instruction, "INVOKEDYNAMIC" is a method call instruction, "INVOKEVIRTUAL" is a method call instruction, and "RETURN" is a method return instruction.

[0208] As shown above, the new class bytecode has new methods, dowork() and increment(), compared to the original class bytecode. These methods are known as "special methods." dowork() and increment() can be used as examples of method #1. The probe() method remains unchanged.

[0209] It should be understood that some instructions of increment() are omitted in the above new class bytecode.

[0210] Move the "special methods", i.e. dowork() and increment(), from the new class HotReplaceProbe to the satellite class HotReplaceProbe$Statellite.

[0211] Satellite bytecodes include:

[0212] "GETFIELD" and "PUTFIELD" are object operation instructions.

[0213] The modified new class bytecode includes:

[0214] As shown above, all methods in the satellite class bytecode are static methods.

[0215] Scan all method bodies of the new class (i.e., all method bodies including the modified new class bytecode and satellite class bytecode) to determine the instructions to be patched. In the above example, the instructions to be patched include the following five instructions:

[0216] INVOKEDYNAMIC HotReplaceProbe.doWork;

[0217] INVOKEVIRTUAL HotReplaceProbe.increment;

[0218] GETFIELD HotReplaceProbe.buffer;

[0219] GETFIELD HotReplaceProbe.counter; and

[0220] PUTFIELD HotReplaceProbe.counter.

[0221] Among them, the instruction INVOKEDYNAMIC HotReplaceProbe.doWork in the modified new class bytecode belongs to type 1, the instruction INVOKEVIRTUAL HotReplaceProbe.increment in the satellite class bytecode belongs to type 4, the instruction GETFIELD HotReplaceProbe.buffer in the satellite class bytecode, the instructions GETFIELD HotReplaceProbe.counter and PUTFIELD HotReplaceProbe.counter in the satellite class bytecode all belong to type 3.

[0222] The following is an example description of the instruction patching method.

[0223] For the INVOKEDYNAMIC HotReplaceProbe.doWork instruction, change it from calling a method in the new class to calling a static method in the satellite class. This means changing the class to which the method belongs. Change the class of the doWork instruction (i.e., the new class HotReplaceProbe) to the satellite class HotReplaceProbe$Statellite. Specifically, change it to INVOKEDYNAMIC HotReplaceProbe$Statellite.doWork.

[0224] The target new class bytecodes obtained after instruction patching include:

[0225] For the INVOKEVIRTUAL HotReplaceProbe.increment instruction, change it from calling a method in the new class to calling a static method in the satellite class. This means changing the class to which the method belongs. Change the class to which the increment instruction belongs (i.e., the new class HotReplaceProbe) to the satellite class HotReplaceProbe$Statellite. Specifically, change it to INVOKESTATIC HotReplaceProbe$Statellite.increment.

[0226] For GETFIELD HotReplaceProbe.buffer, the JVM reflection mechanism can be used to access the private members of the new class and generate help accessors in the satellite class, so more code needs to be generated.

[0227] Specifically, the reflection cache reflect$buffer() accesses the private member buffer of the new class HotReplaceProbe through the reflection mechanism and loads it into the static private member f_buffer_001. The member value is then read by getting the cache get$buffer(). GETFIELD HotReplaceProbe.buffer is modified to call get$buffer(), that is, to INVOKESTATIC HotReplaceProbe$Statellite.get$buffer(…). reflect$buffer() is an example of method #8 mentioned above. get$buffer() is an example of method #9 mentioned above.

[0228] The target satellite bytecodes obtained after instruction patching include:

[0229] "INVOKESTATIC" is a method call instruction. "GETSTATIC" and "PUTSTATIC" are object operation instructions.

[0230] In the above target satellite class bytecode, the instructions between the declaration of dowork and "static increment(Lx / HotReplaceProbe;)V" can be taken as an example of an auxiliary accessor.

[0231] The instruction patching method of GETFIELD HotReplaceProbe.counter and PUTFIELD HotReplaceProbe.counter is similar to the instruction patching method of GETFIELD HotReplaceProbe.buffer. To avoid repetition, it will not be repeated here and is not shown in the above example.

[0232] Example 2:

[0233] In Example 2, the modifications include deleting the method and modifying its signature. The following example illustrates this.

[0234] The original class bytecode includes:

[0235] New bytecode classes include:

[0236] As shown above, the new class bytecode removes the probe2() method from the original class bytecode and modifies the signature of the probe1() method, adding a String type parameter. probe1() is a "special method." probe1() can be used as an example of method #6. probe2() can be used as an example of method #2.

[0237] The above modification method is an incompatible change to the original code, and the new class bytecode can be converted.

[0238] The new class bytecode deletes the method probe2() compared to the original class bytecode. During the conversion process, the method probe2() can be restored and its method body can be modified to throw an unsupported exception.

[0239] The new class bytecode modifies the signature of the method probe1() relative to the original class bytecode and moves the declaration of the method probe1() in the new class bytecode to the satellite class bytecode. During the conversion process, the original method probe1() (i.e., probe1() in the original class bytecode) can be restored, and its method body can be modified to throw an unsupported exception. Alternatively, the method of modifying the signature can be understood as follows. The new class bytecode modifies the signature of the method probe1() relative to the original class bytecode. This can be considered as the new class bytecode deleting the original method probe1() (i.e., probe1() in the original class bytecode) and adding the method probe1() with the modified signature to the satellite class bytecode.

[0240] The converted new class bytecode includes:

[0241] Satellite bytecodes include:

[0242] "ATHROW" is an exception handling instruction.

[0243] The instruction patching method can be referred to Example 1. To avoid repetition, it will not be described here.

[0244] Example 3:

[0245] In Example 3, the modifications include adding the static modifier to the method. The following example illustrates this.

[0246] The original class bytecode includes:

[0247] New bytecode classes include:

[0248] As shown above, the new class bytecode has the static modifier added to the original class bytecode. probe() is a "special method." probe() can be used as an example of method #3.

[0249] The above modification method is an incompatible change to the original code, and the new class bytecode can be converted.

[0250] For methods with the static modifier, static methods are treated as added methods. Defining the method in a satellite class means that the static method is added to the satellite class bytecode. Non-static methods can remain in the new class, and calls are forwarded to the static method in the satellite class.

[0251] Specifically, the new class bytecode adds a static modifier to the probe() method in the original class bytecode, and moves the probe() method declaration in the new class bytecode to the satellite class bytecode. During the conversion of the new class bytecode, the original probe() method (i.e., the probe() method in the original class bytecode) can be restored and its method body modified to call the probe() method in the satellite class bytecode.

[0252] The converted new class bytecode includes:

[0253] Satellite bytecodes include:

[0254] The instruction patching method can be referred to Example 1. To avoid repetition, it will not be described here.

[0255] The process for removing the static modifier from a method is similar to that for adding it. That is, the method after removing the static modifier is treated as an added method. Defining this method in a satellite class means that the removed static method is added to the satellite class bytecode. The method in the original class remains in the new class, and calls are forwarded to the method in the satellite class.

[0256] Specifically, the new class bytecode removes modifiers from a method in the original class bytecode and moves the method declaration in the new class bytecode to the satellite class bytecode. During the conversion of the new class bytecode, the original method (i.e., the method in the original class bytecode) can be restored and its method body modified to call the method in the satellite class bytecode.

[0257] Example 4:

[0258] In Example 4, the modifications include adding the synchronized modifier to the method. The following example illustrates this.

[0259] The original class bytecode includes:

[0260] New bytecode classes include:

[0261] As shown above, the new class bytecode has the synchronized modifier added to the original class bytecode. probe() is a "special method." probe() can be used as an example of method #4.

[0262] The above modification method is an incompatible change to the original code, and the new class bytecode can be converted.

[0263] For methods with the synchronized modifier, the non-synchronized method can be treated as an additional method and added to the satellite class bytecode to maintain compatibility with the original code. The non-synchronized (nosync) method is synchronized using the monitor mechanism. Specifically, the non-synchronized (nosync) method is explicitly wrapped with MONITORENTER / TRY / FINALLY / MONITOREXIT statements to achieve synchronization. The synchronized method in the converted new class calls the synchronized method in the satellite class.

[0264] Specifically, the new class bytecode adds the synchronized modifier to the probe() method compared to the original class bytecode, moves the declaration of the non-synchronized probe() method to the satellite class bytecode, and synchronizes the non-synchronized method. The method body of the synchronized probe() method in the new class bytecode is modified to call the synchronized probe() method in the satellite class bytecode.

[0265] The converted new class bytecode includes:

[0266] Satellite bytecodes include:

[0267] MONITORENTER is the monitor lock instruction, MONITOREXIT is the unlock instruction, and TRYCATCHBLOCK is the exception handling mechanism.

[0268] The instruction patching method can be referred to Example 1. To avoid repetition, it will not be described here.

[0269] Example 5:

[0270] In Example 5, the modification involves removing the synchronized modifier from the method. The following example illustrates this.

[0271] The original class bytecode includes:

[0272] New bytecode classes include:

[0273] As shown above, the new class bytecode has the synchronized modifier removed from the original class bytecode. probe() is a "special method." probe() can be used as an example of method #5.

[0274] The above modification method is an incompatible change to the original code, and the new class bytecode can be converted.

[0275] For methods with the synchronized modifier removed, the non-synchronized method can be considered an added method. Defining the method in the satellite class means that the non-synchronized method is added to the satellite class bytecode. In the converted new class, the non-synchronized method calls the non-synchronized (nosync) method in the satellite class.

[0276] Specifically, the new class bytecode removes the synchronized modifier from the probe() method compared to the original class bytecode, moves the declaration of the asynchronous probe() method to the satellite class bytecode, and modifies the method body of the asynchronous probe() method in the new class bytecode to call the asynchronous probe() method in the satellite class bytecode.

[0277] The converted new class bytecode includes:

[0278] Satellite bytecodes include:

[0279] The instruction patching method can be referred to Example 1. To avoid repetition, it will not be described here.

[0280] The apparatus of the embodiment of the present application is described below with reference to Figures 5 to 8. It should be understood that the apparatus described below can execute the method of the aforementioned embodiment of the present application. To avoid unnecessary repetition, repeated descriptions are appropriately omitted when introducing the apparatus of the embodiment of the present application.

[0281] FIG5 is a schematic block diagram of an apparatus for hot code replacement according to an embodiment of the present application. The apparatus 2000 shown in FIG5 can be used to execute the method shown in FIG1. ​​The apparatus 2000 includes an acquisition module 2010, a generation module 2020, a patching module 2030, and a loading module 2040.

[0282] In one possible implementation, the apparatus 2000 may be used to execute the method shown in 1.

[0283] The acquisition module 2010 is used to acquire a first bytecode and a second bytecode, where the first bytecode is the bytecode compiled from the source code, and the second bytecode is obtained by incrementally compiling the modified source code.

[0284] The generation module 2020 is used to transfer the declaration of the first type of modified content in the modified content relative to the first bytecode in the second bytecode to the third bytecode, where the first type of modified content includes modified content other than the modified method body.

[0285] The patching module 2030 is used to patch at least one instruction in the transferred second bytecode or third bytecode, wherein the at least one instruction is used to call at least one content in the second bytecode, and the patched at least one instruction is used to call the content corresponding to the at least one content in the third bytecode.

[0286] The loading module 2040 is used to load the target second bytecode and the target third bytecode, where part or all of at least one instruction belongs to the transferred second bytecode, and the target second bytecode is obtained by patching part or all of at least one instruction in the transferred second bytecode. In the case where part of at least one instruction belongs to the third bytecode, the target third bytecode is obtained by patching part of at least one instruction in the third bytecode, or, in the case where at least one instruction does not belong to the third bytecode, the target third bytecode is the third bytecode.

[0287] Optionally, the source code is Java source code, and the first type of modification content includes at least one of the following: an added method, a method with a modified signature, a method with a modifier added, a method with a modifier removed, an added lambda expression, a modified body lambda expression, an added inner anonymous class, or a modified inner anonymous class.

[0288] Optionally, at least one instruction includes a first instruction, at least one content includes a first content, the first content belongs to a first type of modified content, the first instruction is used to call the first content in the second bytecode, and the patched first instruction is used to call the first content in the third bytecode.

[0289] Optionally, at least one instruction includes a first instruction, at least one content includes a first method, the first instruction is used to call the first method in the second bytecode, and the patched first instruction is used to call the first method in the third bytecode.

[0290] At least one instruction includes a second instruction, and the second instruction belongs to a third bytecode. The patching module 2030 is specifically used to: generate a first method and a second method in the third bytecode, the first method is used to access the first field value in the transferred second bytecode through a reflection mechanism, and the second method is used to read the first field value; patch the second instruction so that the patched second instruction is used to call the second method.

[0291] Optionally, the first type of modification content includes adding a modifier to the third method or deleting a modifier to the third method, the modifier is a static modifier, the modifier of the third method in the target second bytecode is the same as the modifier of the third method in the first bytecode, and the method body of the third method in the target second bytecode indicates a call to the third method in the third bytecode.

[0292] Optionally, the first type of modification content includes adding a modifier to the fourth method, the modifier is a synchronization modifier, and the generation module 2020 is specifically used to: transfer the declaration of the asynchronous fourth method to the third bytecode; and the modifier of the fourth method in the target second bytecode includes a synchronization modifier, the method body of the fourth method in the target second bytecode indicates a call to the synchronized fourth method in the third bytecode, and the synchronized fourth method is implemented based on a synchronization tool.

[0293] Optionally, the first type of modification content includes deleting the modifier of the fifth method, the modifier is a synchronization modifier, the modifier of the fifth method in the target second bytecode does not include the synchronization modifier, and the method body of the fifth method in the target second bytecode indicates calling the fifth method in the third bytecode.

[0294] Optionally, the first type of modification content includes modifying the signature of the sixth method, the signature of the sixth method in the target second bytecode is the same as the signature of the sixth method in the first bytecode, and the method body of the sixth method in the target second bytecode indicates throwing an unsupported exception.

[0295] Optionally, the source code is Java source code, and the instructions in the second type of modified content in the target second bytecode indicate throwing an unsupported exception, and the second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted inner anonymous class.

[0296] For a detailed description, please refer to the method 100 mentioned above, which will not be repeated here.

[0297] Each module in the apparatus 2000 may be implemented by software or hardware. For example, the implementation of the generation module 2020 will be described below using the generation module 2020 as an example. Similarly, the implementation of other modules may refer to the implementation of the generation module 2020.

[0298] As an example of a software functional unit, the generation module 2020 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the generation module 2020 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0299] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0300] As an example of a hardware functional unit, the generation module 2020 may include at least one computing device, such as a server. Alternatively, the generation module 2020 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0301] The multiple computing devices included in the generation module 2020 can be distributed in the same region or in different regions. The multiple computing devices included in the generation module 2020 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the generation module 2020 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0302] It should be noted that, in other embodiments, the generation module 2020 can be used to execute any step in the method of hot code replacement, and other modules can be used to execute any step in the method of hot code replacement. The steps that each module is responsible for implementing can be specified as needed, and all functions of the device 2000 are realized by implementing different steps in the method of hot code replacement through each module.

[0303] This application also provides a computing device 1000. As shown in Figure 6, computing device 1000 includes a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. Processor 1004, memory 1006, and communication interface 1008 communicate with each other via bus 1002. Computing device 1000 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1000.

[0304] Bus 1002 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG6 shows a single line, but this does not imply a single bus or type of bus. Bus 1002 may include a path for transmitting information between various components of computing device 1000 (e.g., memory 1006, processor 1004, and communication interface 1008).

[0305] The processor 1004 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0306] The memory 1006 may include volatile memory, such as random access memory (RAM). The processor 1004 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0307] Memory 1006 stores executable program code. Processor 1004 executes the executable program code to implement the functions of the aforementioned acquisition module 2010, generation module 2020, patch module 2030, and loading module 2040, thereby implementing the method for hot code replacement. In other words, memory 1006 stores instructions for executing the method for hot code replacement.

[0308] The communication interface 1008 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1000 and other devices or a communication network.

[0309] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0310] As shown in Figure 7, the computing device cluster includes at least one computing device 1000. The memory 1006 in one or more computing devices 1000 in the computing device cluster may store the same instructions for executing the method for hot code replacement.

[0311] In some possible implementations, the memory 1006 of one or more computing devices 1000 in the computing device cluster may also store partial instructions for executing the method for hot code replacement. In other words, the combination of one or more computing devices 1000 can jointly execute the instructions for executing the method for hot code replacement.

[0312] It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster can store different instructions, each for executing a portion of the system's functions for hot code replacement. That is, the instructions stored in the memory 1006 in different computing devices 1000 can implement the functions of one or more of the acquisition module 2010, generation module 2020, patch module 2030, and loading module 2040.

[0313] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG8 shows a possible implementation. As shown in FIG8 , two computing devices 1000A and 1000B are connected via a network. Specifically, the connection to the network is made via a communication interface in each computing device. In this type of possible implementation, the memory 1006 in the computing device 1000A stores instructions for executing the functions of the acquisition module 2010. At the same time, the memory 1006 in the computing device 1000B stores instructions for executing the functions of the generation module 2020, the patching module 2020, and the loading module 2030.

[0314] The connection method between the computing device clusters shown in Figure 8 can be that considering that the code hot replacement method provided in this application may require data storage, it is considered to entrust the functions implemented by the generation module 2020, the patch module 2020 and the loading module 2030 to the computing device 1000B for execution.

[0315] It should be understood that the functions of the computing device 1000A shown in FIG8 may also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices 1000.

[0316] Embodiments of the present application also provide a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform a method for hot code replacement.

[0317] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a method for hot code replacement.

[0318] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for hot code replacement, characterized in that: include: Obtaining a first bytecode and a second bytecode, wherein the first bytecode is a bytecode compiled from a source code, and the second bytecode is obtained by incrementally compiling the modified source code; transferring a declaration of a first type of modification content in the second bytecode relative to the first bytecode to a third bytecode, wherein the first type of modification content includes modification content other than modification of a method body; patching at least one instruction in the transferred second bytecode or the third bytecode, the at least one instruction being used to call at least one content in the second bytecode, and the patched at least one instruction being used to call content in the third bytecode corresponding to the at least one content; Loading a target second bytecode and a target third bytecode, part or all of the at least one instruction belongs to the transferred second bytecode, the target second bytecode is obtained by patching part or all of the at least one instruction in the transferred second bytecode, and in the case where part of the at least one instruction belongs to the third bytecode, the target third bytecode is obtained by patching part of the at least one instruction in the third bytecode, or, in the case where the at least one instruction does not belong to the third bytecode, the target third bytecode is the third bytecode.

2. The method according to claim 1, characterized in that The source code is Java source code, and the first type of modification content includes at least one of the following: an added method, a method with a modified signature, a method with a modifier added, a method with a modifier deleted, an added lambda expression, a lambda expression with a modified body, an added inner anonymous class, or a modified inner anonymous class.

3. The method according to claim 1 or 2, characterized in that: The at least one instruction includes a first instruction, the at least one content includes a first content, the first content belongs to the first type of modified content, the first instruction is used to call the first content in the second bytecode, and the patched first instruction is used to call the first content in the third bytecode.

4. The method according to any one of claims 1 to 3, characterized in that The at least one instruction includes a second instruction, the second instruction belongs to the third bytecode, the at least one content includes a first field value, the second instruction is used to call the first field value in the second bytecode, and patch at least one instruction in the transferred second bytecode or the third bytecode, including: Generate a first method and a second method in the third bytecode, the first method being used to access the first field value in the transferred second bytecode through a reflection mechanism, and the second method being used to read the first field value; The second instruction is patched so that the patched second instruction is used to call the second method.

5. The method according to any one of claims 1 to 4, characterized in that The first type of modification content includes adding a modifier to the third method or deleting a modifier to the third method, the modifier is a static modifier, the modifier of the third method in the target second bytecode is the same as the modifier of the third method in the first bytecode, and the method body of the third method in the target second bytecode indicates calling the third method in the third bytecode.

6. The method according to any one of claims 1 to 5, characterized in that The first type of modification content includes a fourth method of adding a modifier, the modifier being a synchronization modifier, The step of transferring the declaration of the first type of modified content in the second bytecode relative to the modified content in the first bytecode to the third bytecode comprises: Transferring the declaration of the asynchronous fourth method into the third bytecode; Among them, the modifier of the fourth method in the target second bytecode includes the synchronization modifier, the method body of the fourth method in the target second bytecode indicates calling the synchronized fourth method in the third bytecode, and the synchronized fourth method is implemented based on a synchronization tool.

7. The method according to any one of claims 1 to 6, characterized in that The first type of modification content includes deleting the fifth method from the modifier, wherein the modifier is a synchronization modifier, the modifier of the fifth method in the target second bytecode does not include the synchronization modifier, and the method body of the fifth method in the target second bytecode indicates calling the fifth method in the third bytecode.

8. The method according to any one of claims 1 to 7, characterized in that The first type of modification content includes modifying the signature of a sixth method, the signature of the sixth method in the target second bytecode is the same as the signature of the sixth method in the first bytecode, and the method body of the sixth method in the target second bytecode indicates that an unsupported exception is thrown.

9. The method according to any one of claims 1 to 8, characterized in that The source code is Java source code, and the instructions in the second type of modified content in the target second bytecode indicate throwing an unsupported exception, and the second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted internal anonymous class.

10. A device for hot code replacement, characterized in that: include An acquisition module, configured to acquire a first bytecode and a second bytecode, wherein the first bytecode is a bytecode compiled from a source code, and the second bytecode is obtained by incrementally compiling the modified source code; a generating module, configured to transfer a declaration of a first type of modified content in the second bytecode relative to the first bytecode to a third bytecode, wherein the first type of modified content includes modified content other than a modified method body; a patching module, used for patching at least one instruction in the transferred second bytecode or the third bytecode, wherein the at least one instruction is used to call at least one content in the second bytecode, and the patched at least one instruction is used to call content in the third bytecode corresponding to the at least one content; A loading module is used to load a target second bytecode and a target third bytecode, part or all of the at least one instruction belongs to the modified second bytecode, the target second bytecode is obtained by patching part or all of the at least one instruction in the transferred second bytecode, and in the case where part of the at least one instruction belongs to the third bytecode, the target third bytecode is obtained by patching part of the at least one instruction in the third bytecode, or, in the case where the at least one instruction does not belong to the third bytecode, the target third bytecode is the third bytecode.

11. The device according to claim 10, characterized in that The source code is Java source code, and the first type of modification content includes at least one of the following: an added method, a method with a modified signature, a method with a modifier added, a method with a modifier deleted, an added lambda expression, a lambda expression with a modified body, an added inner anonymous class, or a modified inner anonymous class.

12. The device according to claim 10 or 11, characterized in that The at least one instruction includes a first instruction, the at least one content includes a first content, the first content belongs to the first type of modified content, the first instruction is used to call the first content in the second bytecode, and the patched first instruction is used to call the first content in the third bytecode.

13. The device according to any one of claims 10 to 12, characterized in that The at least one instruction includes a second instruction, the second instruction belongs to the third bytecode, the at least one content includes a first field value, the second instruction is used to call the first field value in the second bytecode, and the patching module is specifically used to: Generate a first method and a second method in the third bytecode, the first method being used to access the first field value in the transferred second bytecode through a reflection mechanism, and the second method being used to read the first field value; The second instruction is patched so that the patched second instruction is used to call the second method.

14. The device according to any one of claims 10 to 13, characterized in that The first type of modification content includes adding a modifier to the third method or deleting a modifier to the third method, the modifier is a static modifier, the modifier of the third method in the target second bytecode is the same as the modifier of the third method in the first bytecode, and the method body of the third method in the target second bytecode indicates calling the third method in the third bytecode.

15. The device according to any one of claims 10 to 14, characterized in that The first type of modification content includes a fourth method of adding a modifier, the modifier being a synchronization modifier, The generation module is specifically used for: Transferring the declaration of the asynchronous fourth method into the third bytecode; The modifiers of the fourth method in the target second bytecode include the synchronization modifier, and the method body of the fourth method in the target second bytecode indicates calling the synchronized fourth method in the third bytecode, wherein the synchronized fourth method is implemented based on a synchronization tool.

16. The device according to any one of claims 10 to 15, characterized in that The first type of modification content includes deleting the fifth method from the modifier, wherein the modifier is a synchronization modifier, the modifier of the fifth method in the target second bytecode does not include the synchronization modifier, and the method body of the fifth method in the target second bytecode indicates calling the fifth method in the third bytecode.

17. The device according to any one of claims 10 to 16, characterized in that The first type of modification content includes modifying the signature of a sixth method, the signature of the sixth method in the target second bytecode is the same as the signature of the sixth method in the first bytecode, and the method body of the sixth method in the target second bytecode indicates that an unsupported exception is thrown.

18. The device according to any one of claims 10 to 17, characterized in that The source code is Java source code, and the instructions in the second type of modified content in the target second bytecode indicate throwing an unsupported exception, and the second type of modified content includes at least one of the following: a deleted method, a deleted lambda expression, or a deleted internal anonymous class.

19. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 9.

20. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 9.

21. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 9.

Images