Abnormality processing method and related device

Abstract

The invention provides an exception handling method and a related device, which can be applied to the technical field of computer exception handling. In the technical scheme provided by the invention, under the condition that the to-be-processed bytecode is determined to be abnormal based on the semantic analysis result of the to-be-processed bytecode and the bytecode offset with abnormal capture exists in the first simulation operation stack, a compiler can determine the target bytecode based on the bytecode offset with abnormal capture; and generating an instruction of jumping to the target byte code. Wherein the first simulation operation stack is a simulation operation stack of the to-be-processed byte code. In the method, the compiler can generate the instruction for jumping to the target byte code based on the first simulation running stack, so that the problem that the instruction for jumping to the target byte code cannot be generated when the to-be-processed byte code does not have a corresponding exception table, and then exception processing cannot be performed on the to-be-processed byte code is avoided.

Description

Technical Field

[0001] The present application relates to the technical field of computer exception handling, and in particular to an exception handling method and related devices. Background Art

[0002] The compiler can statically compile dynamic language bytecodes into assembly-like intermediate codes. During the process of statically compiling dynamic language bytecodes into assembly-like intermediate codes, there is a need to perform exception handling on some dynamic language bytecodes.

[0003] At present, an exception handling method may include: in the case where an exception may occur in a dynamic language bytecode to be processed, each entry may be searched in order in the exception table corresponding to the dynamic language bytecode to be processed, and it is determined whether there is a target entry in the exception table, wherein each entry is used to indicate the start bytecode, end bytecode, target bytecode and exception type of the exception, the exception type of the target entry is consistent with the type of exception that may be thrown by the dynamic language bytecode to be processed, and the code between the start bytecode and the end bytecode of the target entry contains the code that may throw an exception in the dynamic language bytecode to be processed. If the target entry exists in the exception table, a jump code may be generated, and the jump code is used to indicate jumping to the target bytecode in the target entry. If the target entry does not exist in the exception table, it is determined whether there is a target entry in the exception table corresponding to the caller of the dynamic language bytecode to be processed or a code that throws an exception is generated.

[0004] However, when the dynamic language bytecode to be processed does not have a corresponding exception table, for example, when the dynamic language bytecode to be processed is a stack bytecode, this method cannot be used to perform exception handling on the dynamic language bytecode to be processed. Summary of the invention

[0005] The present application provides an exception handling method and related devices, which are used to solve the problem in the prior art that when there is no corresponding exception table for the dynamic language bytecode to be processed, it is impossible to perform exception handling on the dynamic language bytecode to be processed based on the exception table.

[0006] In a first aspect, the present application provides an exception handling method, the method comprising: in a case where it is determined based on a semantic analysis result of a bytecode to be processed that an exception exists in the bytecode to be processed and a bytecode offset for capturing the exception exists in a first simulation running stack, determining a target bytecode based on the bytecode offset for capturing the exception, the distance between a position of the target bytecode in all bytecodes to be compiled and a position of the bytecode to be processed in all bytecodes to be compiled being the bytecode offset for capturing the exception, and the first simulation running stack being a simulation running stack of the bytecode to be processed; generating a first instruction, the first instruction being used to instruct a jump to the target bytecode.

[0007] The method can be applied to a dynamic language static compiler, which can run on Figure 1 An example of a dynamic language static compiler is a JavaScript static compiler.

[0008] As an example, the position of the target bytecode in all the bytecodes to be compiled can be the line number of the target bytecode, and the distance between the positions of the bytecode to be processed in all the bytecodes to be compiled can be the line number of the bytecode to be processed. In this example, the bytecode offset of the captured exception can be the difference between the line number of the target bytecode and the line number of the bytecode to be processed.

[0009] Assuming that the bytecode offset of the captured exception is 6 and the line number of the bytecode to be processed is 10, the compiler can determine the line number of the target bytecode as the sum of the line number of the bytecode to be processed and the bytecode offset of the captured exception.

[0010] In the method, the first instruction may be executed by an executor, and the executor may also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0011] In this method, the compiler can generate instructions to jump to the target bytecode based on the simulated running stack of the bytecode to be processed, avoiding the problem that the instruction to jump to the target bytecode cannot be generated when the bytecode to be processed has no corresponding exception table, and thus the exception handling of the bytecode to be processed cannot be performed.

[0012] In some possible implementations, the first simulation execution stack includes multiple variables.

[0013] The method also includes: if there is a target variable among the multiple variables, determining that there is a bytecode offset for capturing the exception in the first simulation running stack, the value of the target variable is the bytecode offset for capturing the exception, or the target variable is a first operand, and the first operand is the operand of the selection path instruction corresponding to the bytecode offset for capturing the exception.

[0014] An example of a path selection instruction is a phi instruction.

[0015] In this method, the compiler can first pop the first variable from the first simulation running stack to determine whether the first variable is the target variable. If the first variable is not the target variable, the compiler can then pop the second variable from the first simulation running stack to determine whether the second variable is the target variable.

[0016] Among them, the distance between the storage position of the first variable in the first simulation running stack and the bottom of the first simulation running stack can be a first distance, and the distance between the storage position of the second variable in the first simulation running stack and the bottom of the first simulation running stack can be a second distance, and the first distance is greater than the second distance.

[0017] In this method, in addition to determining whether the value of the variable in the first simulation running stack is the bytecode offset for capturing the exception, the compiler also needs to determine whether the value of the variable in the first simulation running stack is the first operand. This can avoid the situation where the bytecode offset for capturing the exception is missed when the variable in the first simulation running stack is replaced by the phi instruction.

[0018] In some possible implementations, the method further includes: determining a second simulation running stack based on the first simulation running stack, the second simulation running stack including at least one variable in the first simulation running stack, the distance between the storage position of each variable in the at least one variable in the first simulation running stack and the bottom of the first simulation running stack is smaller than the distance between the storage position of the target variable in the first simulation running stack and the bottom of the first simulation running stack, and the second simulation running stack is used as the simulation running stack of the target bytecode.

[0019] As an example, assuming that the first simulation running stack includes variable 1, variable 2 and variable 3, if the compiler pops variable 1 from the first simulation running stack, and variable 2 and variable 3 are not popped out, variable 2 and variable 3 can be used as variables in the second simulation running stack.

[0020] In this method, the remaining variables in the first simulation running stack can be used as variables in the second simulation running stack, that is, the remaining variables can be reused, which is conducive to saving the storage space of the simulation running stack.

[0021] In some possible implementations, the method further includes: if the bytecode offset for catching the exception does not exist in the first simulation running stack, generating a second instruction, wherein the second instruction is used to instruct to throw an exception.

[0022] In the method, the second instruction may be executed by an executor, and the executor may also run on an operating system of the terminal device.

[0023] In this method, when there is no bytecode offset for catching exceptions in the first simulation running stack, the executor can throw an exception based on the second instruction to perform exception processing on the bytecode to be processed.

[0024] In some possible implementations, the method further includes: generating a third instruction, wherein the third instruction is used to indicate whether the return value of the bytecode to be processed is a target value, wherein the target value is a theoretical return value of the bytecode to be processed obtained by semantically analyzing the bytecode to be processed; and generating a fourth instruction, wherein the fourth instruction is used to indicate that when it is determined that the return value of the bytecode to be processed is not the target value, the first instruction or the second instruction is executed.

[0025] In this method, the return value of the bytecode to be processed may be a value obtained when the executor executes the bytecode to be processed.

[0026] When the compiler performs semantic recognition on the bytecode to be processed, it can determine the target value of the bytecode to be processed based on the semantics of the bytecode to be processed, and the target value can be the theoretical return value when the bytecode to be processed is executed. If the return value obtained by the executor during actual execution is the target value, it can be determined that the return value of the bytecode to be processed is not an abnormal value; if the return value obtained by the executor during actual execution is not the target value, it can be determined that the return value of the bytecode to be processed is an abnormal value.

[0027] Optionally, the fourth instruction may also be used to instruct to execute instructions generated by the compiler based on the next bytecode to be processed when it is determined that the return value of the bytecode to be processed is the target value.

[0028] In the method, the third instruction and the fourth instruction may be executed by an executor, and the executor may also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0029] In the method, when the executor determines that the return value of the bytecode to be processed is not the target value, the executor may execute the first instruction or the second instruction to perform exception processing on the bytecode to be processed.

[0030] In some possible implementations, the third instruction is also used to indicate marking the bytecode to be processed as the last bytecode in the first basic block, and marking the next bytecode of the bytecode to be processed as the first bytecode in the second basic block, and the second basic block is located after the first basic block.

[0031] In this way, only one bytecode that may have an exception can appear in a basic block, which can avoid the situation where, when multiple exceptions appear in a basic block, the instructions generated by the compiler based on a certain exception are mistakenly regarded as instructions generated by the compiler based on another exception, thereby avoiding the situation where the executor executes incorrectly.

[0032] In a second aspect, the present application provides an exception handling device, including modules or units for implementing the method in the first aspect and any possible implementation of the first aspect. It should be understood that each module or unit can implement the corresponding function by executing a computer program.

[0033] As an example, the exception handling device may include a determination module and a generation module.

[0034] The determination module can be used to determine the target bytecode based on the bytecode offset that captures the exception, when it is determined based on the semantic analysis result of the bytecode to be processed that the bytecode to be processed has an exception and there is a bytecode offset that captures the exception in the first simulation running stack, the distance between the position of the target bytecode in all the bytecodes to be compiled and the position of the bytecode to be processed in all the bytecodes to be compiled is the bytecode offset that captures the exception, and the first simulation running stack is the simulation running stack of the bytecode to be processed.

[0035] The generation module may be configured to generate a first instruction, wherein the first instruction is configured to instruct a jump to the target bytecode.

[0036] In some possible implementations, the first simulation execution stack includes multiple variables.

[0037] The determination module can also be used to determine whether there is a bytecode offset for capturing an exception in the first simulation running stack if there is a target variable among the multiple variables, the value of the target variable is the bytecode offset for capturing the exception, or the target variable is a first operand, and the first operand is the operand of a path selection instruction corresponding to the bytecode offset for capturing the exception.

[0038] In some possible implementations, the determination module can also be used to determine a second simulation running stack based on the first simulation running stack, the second simulation running stack including at least one variable in the first simulation running stack, the distance between the storage position of each variable in the at least one variable in the first simulation running stack and the bottom of the first simulation running stack is smaller than the distance between the storage position of the target variable in the first simulation running stack and the bottom of the first simulation running stack, and the second simulation running stack is used as the simulation running stack of the target bytecode.

[0039] In some possible implementations, the generation module may also be configured to generate a second instruction if the bytecode offset for catching the exception does not exist in the first simulation running stack, wherein the second instruction is configured to instruct to throw an exception.

[0040] In some possible implementations, the generation module may also be used to generate a third instruction, where the third instruction is used to instruct to determine whether the return value of the bytecode to be processed is a target value.

[0041] The generation module may also be used to generate a fourth instruction, where the fourth instruction is used to instruct to execute the first instruction or the second instruction when it is determined that the return value of the bytecode to be processed is not the target value.

[0042] In some possible implementations, the third instruction is also used to indicate marking the bytecode to be processed as the last bytecode in the first basic block, and marking the next bytecode of the bytecode to be processed as the first bytecode in the second basic block, and the second basic block is located after the first basic block.

[0043] In a third aspect, the present application provides an exception handling device, comprising a processor, wherein the processor is used to execute the exception handling method described in any possible implementation manner in the first aspect.

[0044] The device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, the methods described in the above aspects may be implemented. The device may further include a communication interface, and the communication interface is used for the device to communicate with other devices. Exemplarily, the communication interface may be a transceiver, circuit, bus, module or other type of communication interface.

[0045] In a fourth aspect, the present application provides a computer-readable storage medium storing a program code for execution by an exception handling device, wherein the program code includes instructions for implementing the method described in any possible implementation manner in the first aspect.

[0046] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on an exception handling device, enables the exception handling device to implement the method described in any possible implementation of the first aspect.

[0047] It can be understood that the effects that can be obtained from the second to fifth aspects can be referred to the description in the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 A schematic diagram of the hardware architecture of a terminal device applicable to an embodiment of the present application;

[0049] Figure 2 A flowchart of an existing method for generating an exception capture mechanism is provided;

[0050] Figure 3 To indicate intention for an abnormality;

[0051] Figure 4 A schematic diagram of a flow chart of an exception handling method provided in one embodiment of the present application;

[0052] Figure 5 A schematic diagram of a first simulation operation stack provided for an embodiment of the present application;

[0053] Figure 6 A flowchart of an exception handling method provided in another embodiment of the present application;

[0054] Figure 7 A schematic diagram of an exception handling device provided in one embodiment of the present application;

[0055] Figure 8 A schematic diagram of an exception handling device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0057] In order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish the same items or similar items with substantially the same functions and effects. For example, the first information and the second information are only used to distinguish different information, and their order is not limited. Those skilled in the art can understand that the words "first" and "second" do not limit the quantity and execution order, and the words "first" and "second" do not necessarily limit them to be different.

[0058] In the embodiments of the present application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Among them, a, b, c can be single or multiple.

[0059] For ease of understanding, the technical terms involved in the embodiments of the present application are introduced below.

[0060] WebAssembly: WebAssembly is a binary instruction format for a stack-based virtual machine, a low-level language similar to assembly, that can be executed in a browser or other WebAssembly runtime system.

[0061] QuickJS: QuickJS is a fast, lightweight, embeddable JavaScript engine developed by Fabrice Bellard. It is an open source project that aims to provide a high-performance JavaScript execution environment that can be easily embedded in various applications such as web browsers, servers, embedded systems, game engines, etc.

[0062] Exception handling: Exception handling is an important concept in computer programming that is used to manage and respond to unusual or error conditions that occur during program execution. An exception is a situation that is inconsistent with the normal program execution flow and may cause the program to crash or produce unpredictable results. The purpose of exception handling is to be able to handle an exception in a controlled manner when it occurs, rather than causing the program to interrupt or crash.

[0063] Exception Catching: To handle the thrown exceptions, the program uses a catch block to catch the exceptions. The catch block contains the code to handle the exceptions. It specifies the actions to be performed so that measures can be taken when an exception occurs, such as logging the error, providing a user-friendly error message, or trying to fix the problem.

[0064] Exception table: The exception table is a table generated by the compiler based on the code during the compilation phase to assist in exception handling at runtime. The exception table contains information such as exception type, exception handler, exception location, and exception handling strategy to ensure that the program can handle various exceptions and provide a mechanism to locate and handle exceptions.

[0065] Stacked bytecode: Stacked bytecode is an intermediate representation or virtual machine instruction set, typically used in an interpreter or compiler for a programming language to perform various operations on high-level source code. Stacked bytecode gets its name from its operand stack, a data structure used to perform operations, usually in a first-in, last-out order.

[0066] Dynamic language bytecode: Dynamic language bytecode is an intermediate code form that is generated by the interpreter of the dynamic language and used to execute the program at runtime. Unlike compiled languages, dynamic languages ​​usually do not convert source code into native machine code at compile time, but interpret and execute line by line at runtime.

[0067] catchoffset: In QuickJS bytecode, catchoffset refers to the offset in the bytecode where the exception is caught. When an exception is thrown, QuickJS looks for the nearest catchoffset in the running stack to determine which bytecode should be used to start executing the catch code that matches the exception.

[0068] Basic block: Basic block is a term in the field of computer programming and compilers, usually used to describe a continuous section of program code with no jump statements (such as conditional branches or loops). A basic block is a code segment that is considered indivisible in the control flow and has a single entry and a single exit.

[0069] Control flow graph: A control flow graph is a graphical data structure used in the compiler field to represent the control flow of a program. It is a graphical way to show the execution order and relationship of various branches, conditions, and jump statements in a program.

[0070] Phi instruction: In the control flow graph, when multiple branches converge to a node, the Phi instruction is used. The role of the Phi instruction is to select an appropriate variable value based on the control flow path of the program. Specifically, if a variable has different values ​​assigned on different branch paths, the Phi instruction at the merge point will select the correct value based on the actual execution path of the program.

[0071] The exception handling method of the present application can be applied to a terminal device, which can be a personal computer (PC), a mobile phone, a tablet computer, a smart screen, a car machine device, a smart watch, etc., and can also be various teaching aids (such as learning machines, early education machines), smart toys, portable robots, personal digital assistants (PDA), augmented reality (AR) equipment, virtual reality (VR) equipment, etc., and can also be a device with mobile office functions, a device with smart home functions, a device with audio and video entertainment functions, a device supporting smart travel, etc. It should be understood that the embodiments of the present application do not limit the specific technology and specific device form adopted by the terminal device.

[0072] In order to better understand the embodiments of the present application, the hardware structure of the terminal device of the embodiments of the present application is introduced below. Figure 1 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application.

[0073] like Figure 1As shown, the terminal device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, etc.

[0074] Optionally, the sensor module 180 may include a pressure sensor 180A, a touch sensor 180B, and the like.

[0075] It is to be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the terminal device. In other embodiments of the present application, the terminal device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0076] The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, etc. Alternatively, the processor 110 may also include a reduced instruction set computing (RISC) processor and a complex instruction set computing (CISC) processor. Among them, different processing units may be independent devices or integrated in one or more processors. A memory may also be provided in the processor 110 for storing instructions and data.

[0077] The USB interface 130 is an interface that complies with the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the terminal device, and can also be used to transfer data between the terminal device and peripheral devices. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other terminal devices, such as AR devices, etc.

[0078] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. While the charging management module 140 is charging the battery 142, it can also charge the terminal device through the power management module 141.

[0079] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory, the camera 193, the display screen 194, the audio module 170 and the wireless communication module 160. In some embodiments, the power management module 141 may also be disposed in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may also be disposed in the same device.

[0080] The wireless communication function of the terminal device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0081] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. The antenna in the terminal device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antenna.

[0082] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied to terminal devices. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1.

[0083] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), etc. applied to the terminal device. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0084] In some embodiments, antenna 1 of the terminal device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that the mobile phone can communicate with the network and other devices through wireless communication technology.

[0085] The camera 193 is used to capture static images or videos. In some embodiments, the terminal device may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0086] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the terminal device may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0087] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos can be stored in the external memory card.

[0088] The internal memory 121 can be used to store computer executable program codes, and the executable program codes include instructions. The internal memory 121 can include a program storage area and a data storage area. Among them, the program storage area can store applications required for at least one function in the operating system (such as a sound playback function, an image playback function, etc.). The data storage area can store data created during the use of the terminal device (such as audio data, a phone book, etc.).

[0089] The terminal device can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor.

[0090] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The speaker 170A, also known as the "speaker", is used to convert audio electrical signals into sound signals. The terminal device can listen to music or listen to hands-free calls through the speaker 170A. The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. When the terminal device answers a call or voice message, the voice can be answered by placing the receiver 170B close to the human ear. The microphone 170C, also known as the "microphone" or "microphone", is used to convert sound signals into electrical signals. The headphone jack 170D is used to connect wired headphones.

[0091] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. When a touch operation acts on the display screen 194, the terminal device can detect the intensity of the touch operation according to the pressure sensor 180A. The terminal device can also calculate the position of the touch according to the detection signal of the pressure sensor 180A. The touch sensor 180B can be set on the display screen 194, and the touch sensor 180B and the display screen 194 form a touch screen, also known as a "touch screen". The touch sensor 180B is used to detect touch operations acting on or near it. The touch sensor 180B can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180B can also be set on the surface of the terminal device, which is different from the position of the display screen 194.

[0092] The key 190 includes a power button, a volume button, etc. The key 190 may be a mechanical key. It may also be a touch key. The terminal device may receive key input and generate key signal input related to user settings and function control of the terminal device. The motor 391 may generate a vibration prompt. The indicator 192 may be an indicator light, which may be used to indicate the charging status, power change, message, missed call, notification, etc. The timer 196 may be used to record time information.

[0093] In the present application, the internal memory 121 of the terminal device may store the operating system of the terminal device. The operating system of the terminal device may be used to run some application programs, such as a compiler and an executor.

[0094] The compiler may include a dynamic language static compiler, which can statically compile dynamic language bytecodes into assembly-like intermediate codes. The dynamic language static compiler can save the compiled codes as executable files, which can be loaded into the internal memory 121 when executing the program.

[0095] The executor may be used to execute the code generated by the compiler. For example, the executor may obtain an executable file from the internal memory 121 and then execute corresponding instructions based on the executable file.

[0096] An example of a dynamic language static compiler is a Java virtual machine (JVM) just-in-time (JIT) compiler. When a program is running, the JVM JIT compiler can statically compile a specific portion of the JVM bytecode into local machine code based on the execution status and performance hotspots of the code.

[0097] During the compilation process of the dynamic language static compiler, the terminal device has a need to handle exceptions for some dynamic language bytecodes. Currently, the terminal device can handle exceptions through an exception capture mechanism, which can be obtained by the terminal device based on the dynamic language static compiler. For the convenience of description, the dynamic language static compiler may be referred to as a compiler in the following application.

[0098] A compiling method for an exception capture mechanism includes: compiling the exception capture mechanism based on an exception table of the bytecode to be processed when it is determined that the bytecode to be processed may cause an exception.

[0099] Taking the JVM JIT compiler as an example, when the terminal device compiles the JVM bytecode based on the JVM JIT compiler, it can generate an exception capture mechanism based on the JVM bytecode and the bytecode exception table, and then handle the exception based on the generated exception capture mechanism. The method for the terminal device to generate an exception capture mechanism based on the JVM JIT compiler can be as follows: Figure 2 shown.

[0100] S201, determine whether the bytecode to be processed may have an exception. If the bytecode to be processed may have an exception, execute S202; if the bytecode to be processed will not have an exception, execute S207.

[0101] In this method, the compiler can perform semantic analysis on the bytecode to be processed to obtain a semantic analysis result, and the semantic analysis result is used to indicate whether an exception may occur in the bytecode to be processed.

[0102] S202, determine whether there is a target entry in the exception table corresponding to the bytecode to be processed. If the target entry exists in the exception table, execute S203; if the target entry does not exist in the exception table, execute S204.

[0103] An exception table may include one or more entries, each of which may be used to indicate a start bytecode, an end bytecode, a target bytecode, and an exception type of an exception.

[0104] As an example, each entry may include a start bytecode index, an end bytecode index, a target bytecode index, and an exception type of the exception.

[0105] like Figure 3 As shown, it is assumed that an exception table may include entry 1 and entry 2. Among them, the starting bytecode index of entry 1 is S1, the ending bytecode index is S2, the target bytecode index is S3, and the exception type is type 1. The starting bytecode index of entry 2 is S4, the ending bytecode index is S5, the target bytecode index is S6, and the exception type is type 2.

[0106] In this method, the compiler can sequentially search for each entry in the exception table corresponding to the bytecode to be processed to determine whether there is a target entry in the exception table corresponding to the bytecode to be processed. The exception type of the target entry is consistent with the type of exception that may occur in the bytecode to be processed, and the code between the start bytecode and the end bytecode of the target entry contains the code that may throw an exception in the bytecode to be processed.

[0107] based on Figure 3 If the exception type of the bytecode to be processed is consistent with the exception type of entry 2, and the index of the bytecode to be processed is between S4 and S5, entry 2 is determined as the target entry.

[0108] S203, generating a first code, where the first code is used to indicate a jump to a target bytecode, where the target bytecode is the target bytecode to be jumped to indicated by the target entry.

[0109] by Figure 3 For example, assuming that entry 2 is the target entry, and the target bytecode index in entry 2 is S6, the first code can be used to indicate a jump to the bytecode indexed as S6.

[0110] S204, determine whether the bytecode to be processed has a caller. If there is a caller, execute S205; if there is no caller, execute S206.

[0111] S205, determining the caller of the bytecode to be processed as the next bytecode to be processed, and executing S202.

[0112] That is, it is determined whether there is a target entry in the exception table of the caller of the bytecode to be processed. The method of determining whether there is a target entry in the exception table of the caller of the bytecode to be processed can be referred to S202, which will not be repeated here.

[0113] S206: Generate a second code, where the second code is used to indicate that an exception is thrown.

[0114] S207, determining the next bytecode of the bytecode to be processed as the next bytecode to be processed, and executing S201.

[0115] That is to say, when there is no exception in the bytecode to be processed, compile the next bytecode of the bytecode to be processed.

[0116] In the prior art, the compiler can compile an exception capture mechanism based on the exception table of the bytecode to be processed. However, when the dynamic language bytecode to be processed does not have a corresponding exception table, for example, when the dynamic language bytecode to be processed is a stack bytecode, the terminal device cannot use this method to generate an exception handling mechanism, and cannot perform exception handling on the dynamic language bytecode to be processed based on the exception capture mechanism.

[0117] To this end, the present application provides an exception handling method for solving the problem in the prior art that the terminal device cannot perform exception handling on the bytecode to be processed based on the compiler.

[0118] In the technical solution of the present application, when the terminal device compiles the bytecode to be processed based on the compiler, it can generate an exception capture mechanism based on the simulated running stack of the bytecode to be processed, and then perform exception handling based on the exception capture mechanism.

[0119] The simulated running stack of the bytecode to be processed may be a running stack for simulating the interpretation and execution of the bytecode to be processed.

[0120] Specifically, when there is a bytecode offset (catchoffset) for catching exceptions in the simulation running stack of the bytecode to be processed, the compiler can determine the target bytecode to be jumped based on the bytecode offset for catching exceptions, and then generate a first instruction, which is used to instruct the jump to the target bytecode.

[0121] The distance between the position of the target bytecode in all the bytecodes to be compiled and the position of the bytecode to be processed in all the bytecodes to be compiled may be the bytecode offset of the captured exception.

[0122] In this method, the terminal device can generate an exception capture mechanism based on the simulated running stack of the bytecode to be processed, thereby avoiding the problem that the exception handling mechanism cannot be generated when the bytecode to be processed has no corresponding exception table, and thus the exception handling cannot be performed based on the exception capture mechanism.

[0123] Next, this application will combine Figures 4 to 8 , the solution of this application is introduced in detail.

[0124] Figure 4 A schematic diagram of a flow chart of an exception handling method provided by an embodiment of the present application. The method may include S401 to S406.

[0125] The method may be executed by a compiler, which may run on an operating system of a terminal device, such as Figure 1 The terminal device shown.

[0126] S401, determining whether the bytecode to be processed may have an exception. If the bytecode to be processed may have an exception, execute S402; if the bytecode to be processed will not have an exception, execute S406.

[0127] In this method, the bytecode to be processed may be a stack bytecode.

[0128] In this method, when compiling the bytecode to be processed, the compiler can perform semantic analysis on the bytecode to be processed to obtain a semantic analysis result, and the semantic analysis result is used to indicate whether the bytecode to be processed may have an exception.

[0129] S402, determine whether there is a bytecode offset for catching an exception in the first simulation running stack. If there is a bytecode offset for catching an exception, execute S403; if there is no bytecode offset for catching an exception, execute S405.

[0130] In the method, the first simulation running stack may be a simulation running stack of the bytecode to be processed. The first simulation running stack may include multiple variables.

[0131] Correspondingly, the method for determining whether there is a bytecode offset for capturing an exception in the first simulation running stack may include: determining whether there is a target variable among multiple variables in the first simulation running stack, the value of the target variable is the bytecode offset for capturing an exception, or the target variable is a first operand, the first operand is the operand of the selection path instruction corresponding to the bytecode offset for capturing the exception. If the target variable exists among the multiple variables, it is determined that there is a bytecode offset for capturing an exception in the first simulation running stack; if the target variable does not exist among the multiple variables, it is determined that there is no bytecode offset for capturing an exception in the first simulation running stack.

[0132] An example of a path selection instruction is a phi instruction.

[0133] In this method, when the compiler determines whether there is a target variable among multiple variables in the first simulation operation, the compiler can pop the first variable among the multiple variables from the first simulation operation stack, and then determine whether the first variable is the target variable. If the first variable is not the target variable, the compiler pops the second variable among the multiple variables from the first simulation operation stack, and then determines whether the second variable is the target variable. If the first variable is the target variable, the compiler stops popping variables from the first simulation operation stack.

[0134] The distance between the storage position of the first variable in the first simulation running stack and the bottom of the first simulation running stack can be a first distance, and the distance between the storage position of the second variable in the first simulation running stack and the bottom of the first simulation running stack can be a second distance, and the first distance is greater than the second distance.

[0135] like Figure 5 As shown, it is assumed that the first simulation running stack includes variable 1, variable 2 and variable 3, wherein variable 3 is stored at the bottom of the stack in the first simulation running stack, and the distance between the storage position of variable 1 in the first simulation running stack and the storage position of variable 3 in the first simulation running stack is greater than the distance between the storage position of variable 2 in the first simulation running stack and the storage position of variable 3 in the first simulation running stack.

[0136] As an example, the compiler may first pop variable 1 from the first simulation run stack to determine whether variable 1 is the target variable. If variable 1 is not the target variable, variable 2 is popped from the first simulation run stack; if variable 1 is the target variable, variables are stopped from being popped from the first simulation run stack. In this example, variable 1 may be the first variable, and variable 2 may be the second variable.

[0137] Optionally, if variable 2 is not the target variable either, variable 3 is popped from the first simulation run stack to determine whether variable 3 is the target variable. In this example, variable 2 may be the first variable, and variable 3 may be the second variable.

[0138] Optionally, if variable 3 is not a target variable either, it is determined that there is no bytecode offset for capturing the exception in the first simulation running stack.

[0139] Optionally, before the compiler pops the variable from the first simulation run, it can also determine whether the variable in the first simulation run stack is empty. If the variable in the first simulation run stack is not empty, the variable is popped from the first simulation run stack. If the variable in the first simulation run stack is empty, it is determined that there is no bytecode offset for catching the exception in the first simulation run stack.

[0140] Optionally, when there may be an exception in the bytecode to be processed, the compiler may also create an exception handling basic block, which may be used to instruct deletion of a non-target variable in at least one variable popped from the first simulation execution stack.

[0141] As a first example, assuming that the compiler pops variable 1 and variable 2 from the first simulation execution stack, variable 1 is not a target variable, and variable 2 is a target variable, then the exception handling basic block can be used to instruct to delete variable 1.

[0142] Optionally, the compiler may pop variable 2 from the first simulation execution stack after variable 1 is deleted.

[0143] Optionally, the compiler may delete variable 1 after determining that variable 2 is the target variable.

[0144] As a second example, assuming that the compiler pops variables 1, 2, and 3 from the first simulation run stack, variables 1 and 2 are not target variables, and variable 3 is the target variable, then the exception handling basic block can be used to indicate the deletion of variables 1 and 2.

[0145] Optionally, the compiler may pop variable 2 from the first simulation execution stack after variable 1 is deleted, and may pop variable 3 from the first simulation execution stack after variable 2 is deleted.

[0146] Optionally, the compiler may delete variable 1 and variable 2 after determining that variable 3 is the target variable.

[0147] As a third example, assuming that the compiler pops variables 1, 2, and 3 from the first simulation run stack, and variables 1, 2, and 3 are not target variables, the exception handling basic block can be used to indicate the deletion of variables 1, 2, and 3.

[0148] Optionally, the compiler may pop variable 2 from the first simulation execution stack after variable 1 is deleted, and pop variable 3 from the first simulation execution stack after variable 2 is deleted, and delete variable 3 after determining that variable 3 is not the target variable.

[0149] Optionally, the compiler may delete variable 1, variable 2, and variable 3 after determining that variable 3 is not a target variable.

[0150] In this method, in addition to determining whether the value of the variable in the first simulation running stack is the bytecode offset for capturing the exception, the compiler also needs to determine whether the value of the variable in the first simulation running stack is the first operand. This can avoid the situation where the bytecode offset for capturing the exception is missed when the variable in the first simulation running stack is replaced by the phi instruction.

[0151] In the method, the instructions in the exception handling basic block may be executed by an executor, and the executor may also run on the operating system of the terminal device.

[0152] S403, determining a target bytecode based on the bytecode offset of the captured exception, wherein the distance between the position of the target bytecode in all bytecodes to be compiled and the position of the bytecode to be processed in all bytecodes to be compiled is the bytecode offset of the captured exception.

[0153] In the method, the target bytecode may be an exception capture code, and the exception capture code may be used to handle the exception.

[0154] As an example, the position of the target bytecode in all bytecodes to be compiled may be the line number of the target bytecode, and the distance between the positions of the bytecode to be processed in all bytecodes to be compiled may be the line number of the bytecode to be processed.

[0155] In this example, the bytecode offset of the captured exception may be the difference between the line number of the target bytecode and the line number of the bytecode to be processed.

[0156] Assuming that the bytecode offset of the captured exception is 6 and the line number of the bytecode to be processed is 10, the compiler can determine the line number of the target bytecode as the sum of the line number of the bytecode to be processed and the bytecode offset of the captured exception.

[0157] S404: Generate a first instruction, where the first instruction is used to instruct to jump to the target bytecode.

[0158] In this method, the compiler may generate the first instruction at the end of the exception handling basic block.

[0159] In the method, the first instruction may be executed by an executor, and the executor may also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0160] In the method, the first instruction may indicate the location of the target bytecode. Accordingly, the executor may execute the step of jumping to the target bytecode based on the location of the target bytecode.

[0161] S405: Generate a second instruction, where the second instruction is used to instruct to throw an exception.

[0162] In this method, the compiler may generate the second instruction at the end of the exception handling basic block.

[0163] In the method, the second instruction can be executed by an executor, and the executor can also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0164] S406: Determine the next bytecode of the bytecode to be processed as the next bytecode to be processed.

[0165] In this method, the terminal device can generate an exception capture mechanism based on the simulated running stack of the bytecode to be processed, thereby avoiding the problem that the exception handling mechanism cannot be generated when the bytecode to be processed has no corresponding exception table, and thus the exception handling cannot be performed based on the exception capture mechanism.

[0166] In the present application, the compiler can also determine a second simulation running stack based on the first simulation running stack, and the second simulation running stack includes at least one variable in the first simulation running stack, and the distance between the storage position of each variable in the at least one variable in the first simulation running stack and the bottom of the first simulation running stack is smaller than the distance between the storage position of the target variable in the first simulation running stack and the bottom of the first simulation running stack, and the second simulation running stack can be used as a simulation running stack for the target bytecode.

[0167] As an example, assuming that the first simulation running stack includes variable 1, variable 2 and variable 3, if the compiler pops variable 1 from the first simulation running stack, and variable 2 and variable 3 are not popped out, variable 2 and variable 3 can be used as variables in the second simulation running stack.

[0168] It should be noted that the first simulation running stack and the second simulation running stack here can be the same stack. The first and second here are only to distinguish the different numbers of variables in the simulation running stack at different times, or the different assignments of variables in the simulation running stack at different times.

[0169] In this method, the remaining variables in the first simulation running stack can be used as variables in the second simulation running stack, that is, the remaining variables can be reused, which is conducive to saving the storage space of the simulation running stack.

[0170] In the present application, the compiler may also generate a third instruction, which may be used to instruct to determine whether the return value of the bytecode to be processed is the target value.

[0171] In the method, the third instruction can be executed by an executor, and the executor can also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0172] In this method, the return value of the bytecode to be processed may be a value obtained when the executor executes the bytecode to be processed.

[0173] When the compiler performs semantic recognition on the bytecode to be processed, it can determine the target value of the bytecode to be processed based on the semantics of the bytecode to be processed, and the target value can be the theoretical return value of the bytecode to be processed. If the return value obtained by the executor during actual execution is the target value, it can be determined that the return value of the bytecode to be processed is not an abnormal value; if the return value obtained by the executor during actual execution is not the target value, it can be determined that the return value of the bytecode to be processed is an abnormal value.

[0174] Optionally, the third instruction is also used to indicate that the bytecode to be processed is marked as the last bytecode in the first basic block, and the next bytecode of the bytecode to be processed is marked as the first bytecode in the second basic block, and the second basic block is located after the first basic block.

[0175] In this way, only one bytecode that may have an exception can appear in a basic block, which can avoid the situation where, when multiple exceptions appear in a basic block, the instructions generated by the compiler based on a certain exception are mistakenly regarded as instructions generated by the compiler based on another exception, thereby avoiding the situation where the executor executes incorrectly.

[0176] Optionally, the compiler may also generate a fourth instruction, where the fourth instruction is used to instruct to execute the first instruction or the second instruction when it is determined that the return value of the bytecode to be processed is not the target value.

[0177] In this method, the compiler may generate the fourth instruction at the end of the basic block where the bytecode to be processed is located.

[0178] The fourth instruction may be executed by an executor, which may also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0179] As an example, when the executor determines that the return value of the bytecode to be processed is an abnormal value, if the compiler generates a first instruction, the first instruction is executed; if the compiler generates a second instruction, the second instruction is executed.

[0180] Optionally, the fourth instruction may also be used to instruct to execute instructions generated by the compiler based on the next bytecode to be processed when it is determined that the return value of the bytecode to be processed is the target value.

[0181] In this method, the compiler may generate the fourth instruction at the end of the basic block where the bytecode to be processed is located.

[0182] In the present application, the compiler can also generate a program control flow graph with an exception catching mechanism based on the exception catching mechanism translator.

[0183] An example of a dynamic language static compiler is a JavaScript static compiler, which may include a QuickJS engine front end, which may be used to parse the JavaScript source code read by the JavaScript static compiler into QuickJS bytecode. The JavaScript static compiler may also read the QuickJS bytecode to construct a basic flow graph of the program, and represent it in the form of an intermediate representation (IR) of the underlying virtual machine (LLVM). The JavaScript static compiler may also compile the QuickJS bytecode into LLVM IR. In the process of compiling LLVM IR, if a bytecode that may throw an exception is encountered, an exception capture mechanism may be generated for the bytecode.

[0184] Figure 6 A flowchart of a method for generating an exception catching mechanism by a JavaScript static compiler provided in one embodiment of the present application.

[0185] S601, the JavaScript static compiler determines whether the bytecode to be processed may have an exception. If the bytecode to be processed may have an exception, S602 is executed; if the bytecode to be processed will not have an exception, S606 is executed.

[0186] In this method, when compiling the bytecode to be processed, the JavaScript static compiler determines whether the bytecode to be processed may have an exception. The method for the JavaScript static compiler to determine whether the bytecode to be processed may have an exception can be referred to S401, which will not be repeated here.

[0187] S601 may be executed in the process of the JavaScript static compiler compiling the QuickJS bytecode into LLVM IR.

[0188] S602, the JavaScript static compiler determines whether there is a bytecode offset for catching exceptions in the simulation running stack of the bytecode to be processed. If there is a bytecode offset for catching exceptions, execute S603; if there is no bytecode offset for catching exceptions, execute S605.

[0189] The simulation running stack of the bytecode to be processed may include multiple variables.

[0190] In this method, when the JavaScript static compiler determines whether there is a bytecode offset that captures an exception in the simulation run stack of the bytecode to be processed, it can determine whether there is a target variable among multiple variables in the simulation run stack of the bytecode to be processed, and the value of the target variable is the bytecode offset that captures the exception in QuickJS, or the target variable is the operand of the selection path instruction corresponding to the bytecode offset that captures the exception in QuickJS. Among them, the step of determining whether there is a target variable among multiple variables in the simulation run stack of the bytecode to be processed can refer to S402, which will not be repeated here.

[0191] Optionally, the JavaScript static compiler may pop a variable from the simulation run stack of the bytecode to be processed, and then determine whether the popped variable is the target variable. If the popped variable is not the target variable, the JavaScript static compiler may pop the next variable from the simulation run stack of the bytecode to be processed.

[0192] The JavaScript static compiler may pop at least one variable from the simulation execution stack of the bytecode to be processed.

[0193] In the case that the bytecode to be processed may have an exception, the compiler may also create an exception handling basic block, which may be used to instruct deletion of a non-target variable in at least one variable popped from the simulation execution stack of the bytecode to be processed.

[0194] S603, the JavaScript static compiler determines the target bytecode based on the bytecode offset of the captured exception, and the distance between the position of the target bytecode in all bytecodes to be compiled and the position of the bytecode to be processed in all bytecodes to be compiled is the bytecode offset of the captured exception.

[0195] The method for the JavaScript static compiler to determine the target bytecode based on the bytecode offset of the captured exception can be referred to S403 and will not be described in detail here.

[0196] S604, the JavaScript static compiler generates a first instruction, where the first instruction is used to instruct to jump to the target bytecode.

[0197] The JavaScript static compiler may generate this first instruction at the end of an exception handling basic block.

[0198] Optionally, the JavaScript static compiler may also use the remaining variables in the simulation run stack of the bytecode to be processed as the simulation run stack of the basic block where the target bytecode is located.

[0199] S605, the JavaScript static compiler generates a second instruction, where the second instruction is used to instruct to throw an exception.

[0200] The JavaScript static compiler may generate this second instruction at the end of the exception handling basic block.

[0201] S606: The JavaScript static compiler determines the next bytecode of the bytecode to be processed as the next bytecode to be processed.

[0202] Optionally, the JavaScript static compiler may also generate a third instruction, which may be used to instruct whether the return value of the bytecode to be processed is the target value.

[0203] Optionally, the third instruction is also used to indicate that the bytecode to be processed is marked as the last bytecode in the first basic block, and the next bytecode of the bytecode to be processed is marked as the first bytecode in the second basic block, and the second basic block is located after the first basic block.

[0204] Optionally, the JavaScript static compiler may also generate a fourth instruction, where the fourth instruction is used to instruct to execute the first instruction or the second instruction when it is determined that the return value of the bytecode to be processed is not the target value.

[0205] In this method, the first instruction, the second instruction, the third instruction, and the fourth instruction generated by the JavaScript static compiler can be executed by an executor, and the executor can also run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0206] Figure 7 A schematic diagram of an exception handling device provided by an embodiment of the present application. Figure 7 As shown, the exception handling device 700 may include a determination module 701 and a generation module 702 .

[0207] As an example, the exception handling device 700 can be used to implement Figure 4 The exception handling method of the illustrated embodiment, wherein the determination module 701 can be used to execute S401, S402, S403 and S406, and the generation module 702 can be used to execute S404 and S405.

[0208] In this example, the exception handling device 700 can be applied to a compiler, and the compiler can run on a computer such as Figure 1 The operating system of the terminal device is shown.

[0209] As another example, the exception handling device 700 can be used to implement Figure 6The exception handling method of the illustrated embodiment, wherein the determination module 701 can be used to execute S601, S602, S603 and S606, and the generation module 702 can be used to execute S604 and S605.

[0210] In this example, the exception handling device 700 can be applied to a JavaScript static compiler, which can run on a Figure 1 The operating system of the terminal device is shown.

[0211] Figure 8 A schematic diagram of an exception handling device provided in another embodiment of the present application. Figure 8 As shown, the exception handling device 800 includes a processor 801 and an interface circuit 802. The processor 801 and the interface circuit 802 are coupled to each other. It is understandable that the interface circuit 802 can be a transceiver or an input-output interface. Optionally, the exception handling device 800 can also include a memory 803 for storing instructions executed by the processor 801 or storing input data required by the processor 801 to run the instructions or storing data generated after the processor 801 runs the instructions.

[0212] As an example, the processor 801 may be configured to implement the functions of the above-mentioned determination module 701 and generation module 702 .

[0213] In this example, the exception handling device 800 may be a terminal device, or a chip used in the terminal device. The terminal device may be Figure 1 The terminal device shown.

[0214] The method steps in the embodiments of the present application can be implemented by hardware, or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a network device or a terminal device. Of course, the processor and the storage medium can also be present in a network device or a terminal device as discrete components.

[0215] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed on a computer, the process or function described in the embodiment of the present application is executed in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device or other programmable device. The computer program or instruction may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instruction may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium may be a magnetic medium, for example, a floppy disk, a hard disk, a tape; it may also be an optical medium, for example, a digital video disc; it may also be a semiconductor medium, for example, a solid-state hard disk.

[0216] In the various embodiments of the present application, unless otherwise specified or provided for in any logical conflict, the terms and / or descriptions between the different embodiments are consistent and may be referenced to each other, and the technical features in the different embodiments may be combined to form new embodiments according to their inherent logical relationships.

[0217] It is understood that the various numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic.

Claims

1. An exception handling method, characterized in that: The method comprises: In the case where it is determined based on the semantic analysis result of the bytecode to be processed that the bytecode to be processed has an exception and there is a bytecode offset for catching the exception in the first simulation running stack, a target bytecode is determined based on the bytecode offset for catching the exception, the distance between the position of the target bytecode in all the bytecodes to be compiled and the position of the bytecode to be processed in all the bytecodes to be compiled is the bytecode offset for catching the exception, and the first simulation running stack is a simulation running stack of the bytecode to be processed; A first instruction is generated, where the first instruction is used to instruct to jump to the target bytecode.

2. The method according to claim 1, characterized in that The first simulation operation stack includes a plurality of variables; The method further comprises: If there is a target variable among the multiple variables, it is determined that there is a bytecode offset for capturing the exception in the first simulation running stack, and the value of the target variable is the bytecode offset for capturing the exception, or the target variable is the first operand, and the first operand is the operand of the selection path instruction corresponding to the bytecode offset for capturing the exception.

3. The method according to claim 2, characterized in that The method further comprises: A second simulation running stack is determined based on the first simulation running stack, the second simulation running stack includes at least one variable in the first simulation running stack, the distance between the storage position of each variable in the at least one variable in the first simulation running stack and the bottom of the first simulation running stack is smaller than the distance between the storage position of the target variable in the first simulation running stack and the bottom of the first simulation running stack, and the second simulation running stack is used as the simulation running stack of the target bytecode.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: If the bytecode offset for capturing the exception does not exist in the first simulation running stack, a second instruction is generated, where the second instruction is used to instruct to throw an exception.

5. The method according to claim 4, characterized in that The method further comprises: Generate a third instruction, the third instruction is used to instruct to determine whether the return value of the bytecode to be processed is a target value, the target value is a theoretical return value of the bytecode to be processed obtained by semantically analyzing the bytecode to be processed; A fourth instruction is generated, where the fourth instruction is used to instruct to execute the first instruction or the second instruction when it is determined that the return value of the bytecode to be processed is not the target value.

6. The method according to claim 5, characterized in that The third instruction is also used to indicate marking the bytecode to be processed as the last bytecode in the first basic block, and marking the next bytecode of the bytecode to be processed as the first bytecode in the second basic block, and the second basic block is located after the first basic block.

7. An exception handling device, characterized in that: The method comprises a functional module for implementing the method according to any one of claims 1 to 6.

8. An exception handling device, characterized in that: include: Memory and processor; The memory is used to store program instructions; The processor is configured to execute program instructions in the memory to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program code for computer execution, wherein the program code includes instructions for implementing the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The computer program product comprises instructions for implementing the method according to any one of claims 1 to 6.

Images