Exception handling method for application runtime, restricted device, terminal and medium

Abstract

The application discloses an exception processing method for an application runtime, a limited device, a terminal and a medium, and relates to the technical field of application runtime exception processing. The method comprises the following steps: when a first virtual machine is used to execute bytecode, in response to a call to an exception processing container, suspending the first virtual machine and transmitting at least one parameter into the exception processing container; the at least one parameter comprises a first parameter used for locating a first function, and the first function comprises logic code needing to be monitored for an exception; executing the exception processing container, starting and using a second virtual machine to execute the first function after the exception processing container locates the first function corresponding to the first parameter; and exiting the second virtual machine and executing a process matched with a first execution result of the first function when the first execution result is acquired through the exception processing container. The application embodiment can save storage space when performing exception processing of an application in a system with limited resources, can avoid that a program cannot run when an exception is nested or a high optimization level is used, and improves the reliability of exception processing.

Description

Application runtime exception handling methods, restricted devices, terminals and media Technical Field

[0001] This invention relates to the field of embedded system application technology, and in particular to an exception handling method, apparatus, restricted device, terminal, medium and product for application runtime. Background Technology

[0002] WebAssembly (WASM) is a virtual instruction set architecture. Based on WebAssembly bytecode technology, applications can be written in various programming languages, converted into WebAssembly bytecode, and then interpreted and executed by the virtual machine to enable the application to run correctly. However, WebAssembly bytecode applications do not support exception handling.

[0003] Existing exception handling implementations based on WebAssembly bytecode often require significant storage space to store various parameters, and some implementations also suffer from low reliability. In particular, when configuring WebAssembly bytecode applications on resource-constrained devices, these existing exception handling implementations may negatively impact the application's normal operation due to excessive consumption of storage resources.

[0004] In view of this, it is necessary to propose a new way of exception handling during application runtime to effectively adapt to embedded operating systems in resource-constrained environments. Summary of the Invention

[0005] This invention provides a method, apparatus, restricted device, terminal, medium, and product for handling exceptions during application runtime, so as to realize exception handling of WebAssembly-based applications running in resource-constrained environments.

[0006] According to one aspect of the present invention, an exception handling method for application runtime is provided, comprising:

[0007] During the execution of bytecode using the first virtual machine, in response to a call to the exception handling container, the first virtual machine is suspended, and at least one parameter is passed to the exception handling container; wherein, at least one parameter includes a first parameter, which is used to locate the first function, and the first function contains the logic code that needs to monitor exceptions;

[0008] The exception handling container is executed, and after locating the first function corresponding to the first parameter through the exception handling container, the second virtual machine is started and used to execute the first function.

[0009] When the exception handling container obtains the first execution result of the first function, it exits the second virtual machine and executes a processing flow that matches the first execution result.

[0010] According to another aspect of the present invention, an exception handling apparatus for application runtime is also provided, the apparatus comprising:

[0011] The exception handling container invocation module is used to suspend the first virtual machine in response to a call to the exception handling container during the execution of bytecode using the first virtual machine, and pass at least one parameter to the exception handling container; wherein, at least one parameter includes a first parameter, which is used to locate the first function, and the first function contains the logic code that needs to monitor exceptions;

[0012] An exception handling container execution module is used to execute an exception handling container, and after locating the first function corresponding to the first parameter through the exception handling container, start and use the second virtual machine to execute the first function.

[0013] The first execution result execution module is used to exit the second virtual machine and execute a processing flow that matches the first execution result when the exception handling container obtains the first execution result of the first function.

[0014] According to another aspect of the present invention, a confined device is provided, the confined device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the exception handling method for application runtime as described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a terminal is also provided, including a restricted device as described in any one of the embodiments of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the exception handling method for application runtime as described in any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0021] The technical solution of this invention, in response to a call to an exception handling container during the execution of bytecode using a first virtual machine, suspends the first virtual machine and passes a parameter containing a first parameter to the exception handling container; executes the exception handling container, locates the first function corresponding to the first parameter through the exception handling container, starts and uses a second virtual machine to execute the first function; and when the exception handling container obtains the first execution result of the first function, exits the second virtual machine and executes a processing flow matching the first execution result. Compared with the exception handling implementation method of defining special identifiers as conditional statements in the code, this invention encapsulates the logic code that needs to monitor exceptions in the form of a function in the exception handling container. This avoids the situation where the bytecode conversion tool optimizes the content before and after the conditional statements when the optimization level is high, thus causing the exception handling function to fail. This improves the reliability of exception handling. In addition, the implementation method of this invention can effectively avoid generating too much exception handling information, thereby effectively reducing the occupation of storage space. It is particularly suitable for runtime exception handling of WebAssembly applications running on resource-constrained devices.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 is a flowchart of an exception handling method for application runtime provided according to an embodiment of the present invention;

[0025] Figure 2 is a flowchart of another exception handling method for application runtime provided according to an embodiment of the present invention;

[0026] Figure 3 is a flowchart of another exception handling method for application runtime provided according to an embodiment of the present invention;

[0027] Figure 4 is a schematic diagram of a specific application scenario to which the embodiments of the present invention are applicable;

[0028] Figure 5 is a structural diagram of an exception handling device for application runtime provided according to an embodiment of the present invention;

[0029] Figure 6 is a structural diagram of a confined device according to an embodiment of the present invention;

[0030] Figure 7 is a structural diagram of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] Figure 1 is a flowchart of an exception handling method for application runtime provided by an embodiment of the present invention. This embodiment is applicable to the situation of exception handling for application runtime in an embedded operating system. The method can be executed by an exception handling device for application runtime. The device can be implemented in hardware and / or software and can generally be configured in a restricted device (e.g., various security elements or smart cards) with an embedded operating system installed.

[0034] The method in this embodiment can be executed by a runtime environment within an embedded operating system. Specifically, it is executed by multiple virtual machines within the runtime environment combined with an exception handling container. The runtime environment is a secure runtime environment that executes virtual machines on constrained resources such as smart cards or secure elements, and can be considered a type of ultra-lightweight container. The application runs within the runtime environment, thus achieving complete isolation from the native functions of the embedded operating system.

[0035] Accordingly, as shown in Figure 1, the method includes:

[0036] S110. During the execution of bytecode using the first virtual machine, in response to a call to the exception handling container, the first virtual machine is suspended, and at least one parameter is passed to the exception handling container.

[0037] Among them, at least one parameter includes a first parameter, which is used to locate the first function, and the first function contains the logic code that needs to monitor exceptions.

[0038] In this embodiment of the invention, the virtual machine can be specifically understood as a bytecode interpreter, a multi-application smartcard operation system (AOS) application running in a resource-constrained environment (such as a smart card, secure element, and embedded device), and a lightweight core component providing a secure execution environment. The AOS operating system is an operating system that supports multiple applications, is downloaded later, and runs on a resource-constrained secure chip.

[0039] The first virtual machine can understand a bytecode interpreter that is currently executing bytecode in the runtime environment.

[0040] In this embodiment of the invention, the exception handling container can be specifically understood as a system interface provided by the runtime environment. This system interface defines the execution and control logic for the passed-in first function. When writing application code, developers can introduce the exception handling container at the code location where exception monitoring is required. Then, by calling the interface, the logic defined in the exception handling container can be executed, achieving the purpose of executing the aforementioned logic code that needs to monitor exceptions.

[0041] With the above settings, the exception handling mechanism can be triggered simply by calling the interface, without extending the virtual machine bytecode.

[0042] Furthermore, in the various embodiments of this invention, instead of constructing an exception detection instruction (typically a Try instruction) and writing the logic code to be monitored for exceptions within that instruction, as is common in existing technologies, the logic code to be monitored for exceptions is placed within a function, such as a tryBlock function (also known as a code block function). Optionally, developers can develop one or more tryBlock functions according to actual needs. Alternatively, the aforementioned code block function can be understood as all the code within the try{} block in exception keyword programming languages.

[0043] Specifically, an exception handling container can be defined in the form of: u32 exceptionProcess(first parameter, ...). Furthermore, developers can add the logic to call the exception handling container at the location where the tryBlock function needs to be executed, and pass the first parameter used to locate the tryBlock function (i.e., the first function) to the called exception handling container.

[0044] The first parameter can be the address information or function index information of the first function to be executed, etc., and this embodiment does not impose any restrictions on it.

[0045] In this embodiment of the invention, the first function can be specifically understood as a code block that needs to monitor exceptions, expressed in the form of a function. Exception handling containers can be nested within this code block function.

[0046] It needs to be emphasized again that this exception handling container is a system interface. After this system interface is called and executed, the processing logic defined within the system interface will be executed. This processing logic is different from bytecode and does not require bytecode interpreter for execution. At this point, the first virtual machine can be suspended. Suspension can be understood as saving the execution environment of the first virtual machine so that after the exception handling container exits execution, the first virtual machine can continue executing the bytecode following the exception handling container in the saved execution environment.

[0047] In this embodiment, the at least one parameter passed to the exception handling container may include only the first parameter, or it may further include other parameters, such as the location information of the parameters required during the execution of the first function, or the information of other functions to be executed in the exception handling container. This embodiment does not impose any restrictions on this.

[0048] This invention implements exception handling by designing and calling an exception handling container, avoiding the need to record exception data in non-volatile storage space. It also prevents excessive allocation of volatile storage space caused by nested exception handling, thus ensuring smooth program operation. This not only saves storage space but also enhances program stability and efficiency through centralized processing and unified resource management. When compiling the source code, exception handling logic is defined in function form, effectively avoiding the risk of losing exception handling information during high-optimization compilation, ensuring consistency and reliability of exception handling under various optimization settings.

[0049] S120. Execute the exception handling container, and after locating the first function corresponding to the first parameter through the exception handling container, start and use the second virtual machine to execute the first function.

[0050] As mentioned earlier, after a call to the exception handling container is detected in the first virtual machine, the exception handling container can be executed directly outside the first virtual machine. That is, the exception handling container autonomously executes the processing logic defined inside it.

[0051] Specifically, the processing logic executed by the exception handling container is as follows: after locating the first function corresponding to the first parameter, start and use the second virtual machine to execute the first function.

[0052] It should be noted that the first function is a pre-built function containing the logic code that needs to monitor exceptions. This function is also compiled into bytecode during the program code compilation process. Therefore, this first function cannot be executed inside the exception handling container; instead, it also needs to be interpreted and executed by the bytecode interpreter.

[0053] In this embodiment, the second virtual machine and the first virtual machine are both bytecode interpreters. The second virtual machine may be the same as or different from the first virtual machine. However, regardless of whether the second virtual machine is the same as or different from the first virtual machine, the current virtual machine runtime environment must be saved before executing the exception handling container (that is, the aforementioned operation of suspending the first virtual machine).

[0054] In an optional implementation of this embodiment, the second virtual machine can be a new bytecode interpreter that is different from the first virtual machine. Accordingly, whenever an exception handling container is invoked, a new virtual machine is started within the exception handling container to execute the function passed in to the exception handling container, typically the first function.

[0055] With the above settings, in scenarios involving nested exception handling, different virtual machines can execute code block functions defined in different nesting levels, ensuring that exception handling logic at different nesting levels can be executed accurately and efficiently.

[0056] In another optional implementation of this embodiment, the second virtual machine can share the same bytecode interpreter as the first virtual machine. Accordingly, the current virtual machine runtime environment can be saved first, and then an exception handling container can be invoked. Within the exception handling container, the first virtual machine can continue to execute the first function. Subsequently, after exiting the call to the exception handling container, the saved virtual machine runtime environment needs to be restored accordingly, and the first virtual machine can continue to run.

[0057] S130. When the exception handling container obtains the first execution result of the first function, it exits the second virtual machine and executes the processing flow that matches the first execution result.

[0058] As mentioned above, the second virtual machine is only used to execute the first function that the exception handling container cannot resolve. After the second virtual machine completes the execution of the first function and obtains the corresponding first execution result, the exception handling container can exit the second virtual machine and continue to execute the subsequent processing logic defined in the exception handling container.

[0059] In an optional implementation of this embodiment, executing a processing flow that matches the first execution result may include:

[0060] If the exception handling container determines that at least one parameter contains only the first parameter, it exits the exception handling container directly and wakes up the first suspended virtual machine.

[0061] In certain special application execution scenarios, it may be necessary to execute only the logic code that monitors exceptions, without needing to handle exceptions. For example, some protected code segments can be placed in the later parts of a first function. If an exception occurs during the execution of the code preceding the first function, the execution of the first function can be terminated directly. In this case, the technical effect of skipping the execution of the aforementioned protected code when an exception occurs can be achieved. Based on this, only the first parameter can be passed to the exception handling container. After the execution of the first function is completed, the exception handling container can be exited directly, and the first virtual machine can be woken up to continue executing the subsequent bytecode in the first virtual machine.

[0062] Here, waking up the first virtual machine can be understood as restoring the execution environment corresponding to the first virtual machine.

[0063] For example, the exception handling container can be defined as `u32 exceptionProcess(void* tryBlock)`. When writing the application, the logic code that needs to monitor exceptions is placed in a function (such as the function `tryBlock`), i.e., the first function. When the first virtual machine executes bytecode of the form "If(exceptionProcess(&tryBlock)==OK){}", the exception handling container is called, suspending the first virtual machine and passing the first parameter (*tryBlock) to the exception handling container. After locating the first function corresponding to the first parameter, the exception handling container starts and uses the second virtual machine to execute the code in the `tryBlock` function. When the exception handling container obtains the first execution result of the first function, it exits the second virtual machine and executes the processing flow matching the first execution result.

[0064] Optionally, at least one parameter may also include a second parameter, which is used to locate the first parameter array, which contains all the parameters required during the execution of the first function.

[0065] Accordingly, after locating the first function corresponding to the first parameter through the exception handling container, starting and using the second virtual machine to execute the first function may further include: locating the first function corresponding to the first parameter through the exception handling container, locating and obtaining the first parameter array corresponding to the second parameter; starting and using the second virtual machine through the exception handling container, and executing the first function based on the first parameter array.

[0066] For example, the exception handling container is defined as `u32 exceptionProcess(void*tryBlock, u32*tryParam)`. The logic code that needs to monitor exceptions is placed in a function (e.g., the function `tryBlock`), i.e., the first function. If the first function needs parameters during execution, these parameters are stored in an array (e.g., the array `tryParam[]`), i.e., the first parameter array. When the first virtual machine executes bytecode of the form "If(exceptionProcess(&tryBlock,tryParam)==OK){}", the exception handling container is called, suspending the first virtual machine, and the first parameter (`*tryBlock`) and the second parameter (`tryParam`) are passed to the exception handling container. The exception handling container locates the first function corresponding to the first parameter, and after locating and obtaining the first parameter array corresponding to the second parameter, it starts the second virtual machine. The second virtual machine then uses the parameters in the `tryParam` array to execute the code in the `tryBlock` function. When the exception handling container obtains the first execution result of the first function, it exits the second virtual machine and executes the processing flow matching the first execution result.

[0067] Optionally, executing a processing flow matching the first execution result through the exception handling container may include: if the exception handling container determines that at least one parameter contains only the first parameter and the second parameter, then directly exiting the exception handling container and waking up the suspended first virtual machine.

[0068] As mentioned earlier, for application execution scenarios where only logic code requiring exception monitoring needs to be executed, but exception handling is not required, if the logic code requiring exception monitoring needs to use one or more parameters during execution, only the first parameter (used to locate the first function) and the second parameter (used to locate the first parameter array) can be passed to the exception handling container. After the execution of the first function is completed based on the first parameter array, the exception handling container can be exited directly, and the first virtual machine can be woken up to continue executing subsequent bytecode in the first virtual machine.

[0069] The technical solution of this invention, in response to a call to an exception handling container during the execution of bytecode using a first virtual machine, suspends the first virtual machine and passes a parameter containing a first parameter to the exception handling container; executes the exception handling container, locates the first function corresponding to the first parameter through the exception handling container, starts and uses a second virtual machine to execute the first function; and when the exception handling container obtains the first execution result of the first function, exits the second virtual machine and executes a processing flow matching the first execution result. Compared with the exception handling implementation method of defining special identifiers as conditional statements in the code, this invention encapsulates the logic code that needs to monitor exceptions in the form of a function in the exception handling container. This avoids the situation where the bytecode conversion tool optimizes the content before and after the conditional statements when the optimization level is high, thus causing the exception handling function to fail. This improves the reliability of exception handling. In addition, the implementation method of this invention can effectively avoid generating too much exception handling information, thereby effectively reducing the occupation of storage space. It is particularly suitable for runtime exception handling of WebAssembly applications running on resource-constrained devices.

[0070] Based on the above embodiments, suspending the first virtual machine through an exception handling container further includes: recording various running status information in the runtime environment of the first virtual machine through the exception handling container, wherein the running status information includes a program counter and a virtual machine stack pointer;

[0071] Accordingly, waking up the suspended first virtual machine through the exception handling container further includes: restoring the running state information required to run the first virtual machine based on the recorded results through the exception handling container.

[0072] The program counter records the address of the currently executing bytecode instruction, while the stack pointer records the stack frame pointing to the current method call. When the virtual machine is suspended, this runtime state information is saved, allowing the virtual machine to accurately return to its state before suspension upon resumption, continuing bytecode execution without starting from scratch, thus ensuring application continuity and data consistency.

[0073] After the first function is executed, the exception handling container restores the running state information of the first virtual machine based on the recorded results, and performs subsequent processing based on the execution results. This improves the efficiency of program recovery after exception handling, enables rapid response and exception handling, reduces program interruption time caused by exceptions, enhances user experience, and improves the reliability of exception handling during program execution.

[0074] Optionally, recording various runtime status information in the first virtual machine runtime environment through the exception handling container may include: using temporary variables through the exception handling container to record various runtime status information in the first virtual machine runtime environment; wherein, the temporary variables are dynamically stored in the runtime stack of the operating system.

[0075] Specifically, when suspending the currently running virtual machine, temporary variables allocated in the operating system's runtime stack are used to record key data such as the program counter and stack pointer in the current virtual machine's runtime environment.

[0076] Temporary variables are data used during application runtime that are cleared or reset when specific events occur to ensure security and protect sensitive data. They are typically declared inside functions, making them simple and straightforward to use without requiring complex data structures or additional storage management.

[0077] In embedded operating systems, temporary variables are dynamically stored in the operating system's runtime stack. This runtime stack is a volatile storage area and does not occupy any non-volatile storage space, which helps optimize memory usage. Correspondingly, when exiting the exception handling container, the virtual machine information recorded in the temporary variables is restored to wake up the suspended virtual machine.

[0078] By setting up the above, we avoid allocating additional volatile storage space to build a cache stack, and at the same time, we do not need to record exception handling information data in non-volatile storage space, thus saving space and avoiding the problem of excessive exception nesting levels causing program failure to run, thereby improving the reliability of exception handling during application runtime.

[0079] Figure 2 is a flowchart of another exception handling method for application runtime provided by an embodiment of the present invention. This embodiment refines the above embodiments. Specifically, at least one parameter includes a third parameter, which is used to locate a second function. The second function contains logic code to be executed after an exception occurs during the execution of the first function. This specifies the operation of the exception handling container to perform a processing flow that matches the first execution result. Accordingly, as shown in Figure 2, the method includes:

[0080] S210. During the execution of bytecode using the first virtual machine, in response to a call to the exception handling container, the first virtual machine is suspended, and at least one parameter is passed to the exception handling container.

[0081] At least one parameter includes a first parameter and a third parameter. The first parameter is used to locate a first function, which contains logic code that needs to monitor for exceptions. The third parameter is used to locate a second function, which contains logic code to be executed after an exception occurs during the execution of the first function. Of course, at least one parameter may or may not include the first parameter data used by the first function.

[0082] Similarly, in the embodiments of this invention, instead of constructing an exception-catching instruction (typically a Catch instruction) paired with the exception detection instruction and writing the exception-handling logic code in that instruction, as is the case in the prior art, the exception-handling logic code is also placed in a function, such as a catchBlock function (also called an exception handling block function). Optionally, developers can develop one or more catchBlock functions paired with tryBlock functions according to actual needs. Alternatively, the exception handling block function can be understood as all the code in catch{} and / or finally{} in exception keyword programming languages.

[0083] Specifically, an exception handling container can be defined in the form of: `u32 exceptionProcess(first parameter, ..., third parameter, ...)`. Then, when this exception handling container is invoked, the first function pointed to by the first parameter is executed first. If an exception occurs in the first function, the execution logic defined in the exception handling container jumps to the second function pointed to by the third parameter for exception handling. That is, the second function contains the logic code to be executed after an exception occurs during the execution of the first function.

[0084] The third parameter can be the address information or function index information of the second function to be executed during the abnormal jump, etc., and this embodiment does not impose any restrictions on it.

[0085] S220. Execute the exception handling container, and after locating the first function corresponding to the first parameter through the exception handling container, start and use the second virtual machine to execute the first function.

[0086] S230. When the exception handling container obtains the first execution result of the first function, it exits the second virtual machine.

[0087] As mentioned earlier, the second virtual machine is only used to execute the functions called in the exception handling container. Once the function execution is complete, the exception handling container exits the second virtual machine and executes its own internal processing logic.

[0088] S240. The first execution result is judged by the exception handling container: if the first execution result is determined to be an execution exception, then S250 is executed; if the first execution result is determined to be an execution normal result, then S260 is executed.

[0089] In this embodiment, if the parameters passed to the exception handling container include a third parameter, it indicates that an exception generated during the execution of the first function needs to be handled. Therefore, the exception handling container needs to use its own logic to judge the first execution result.

[0090] S250. After locating the second function corresponding to the third parameter, start and use the second virtual machine to execute the second function, and execute S270.

[0091] When the first execution result is an execution exception, it indicates that an exception occurred during the execution of the first function. At this time, the exception handling container needs to locate the bytecode of the second function using the function index of the second function recorded in the third parameter, and restart the second virtual machine to interpret and execute the bytecode corresponding to the second function.

[0092] In this embodiment, the same second virtual machine is used when executing the first function and the second function. That is, only one virtual machine is allocated for each exception handling container that is called and executed. Through the above setting, virtual machine resources can be effectively saved while effectively controlling the accuracy of the nesting relationship of exception handling containers.

[0093] Furthermore, it should be noted that after an exception occurs during the execution of the first function in the exception handling container, the operation performed on the second virtual machine is to exit directly rather than suspend it. This is because the system environment required by the second virtual machine during execution is consistent with the system environment of the exception handling container. Therefore, there is no need to retain the running state information of the second virtual machine, and directly exiting the second virtual machine can further reduce the waste of memory resources.

[0094] For example, the exception handling container is defined as u32 exceptionProcess(void*tryBlock,…,void*catchBlock). The logic code that needs to monitor exceptions is the first function tryBlock, and the logic code to be executed after an exception occurs during the execution of the first function is the second function catchBlock.

[0095] When the first virtual machine executes bytecode of the form "If(exceptionProcess(&tryBlock,…,&catchBlock)==OK){}", the exception handling container is invoked, the first virtual machine is suspended, and the first parameter (&tryBlock) and the third parameter (&catchBlock) are passed to the exception handling container.

[0096] After locating the first function `tryBlock` corresponding to the first parameter, the exception handling container starts and executes the code within the second virtual machine using the first function `tryBlock`. When the exception handling container obtains the first execution result of the first function, it first exits the second virtual machine and uses its own logic code to judge the first execution result. If the first execution result is determined to be an execution exception, the exception handling container locates the second function `catchBlock` corresponding to the third parameter, restarts the second virtual machine, and executes the second function `catchBlock` to handle the exception generated during the execution of the first function. The exception handling container then obtains the execution result of the second function, exits the second virtual machine, and executes the processing flow matching the second execution result.

[0097] S260, Exit the exception handling container directly and wake up the first suspended virtual machine.

[0098] When the first execution result is normal, it means that no exception handling is required. At this time, the exception handling container can be exited directly, and the suspended first virtual machine can be woken up to continue executing the bytecode after the exception handling container.

[0099] S270. When the exception handling container obtains the second execution result of the second function, it exits the second virtual machine and executes the processing flow that matches the second execution result.

[0100] In an optional implementation of this embodiment, executing a processing flow that matches the second execution result through an exception handling container may include:

[0101] If the exception handling container determines that the second execution result is normal, it exits the exception handling container directly and wakes up the suspended first virtual machine.

[0102] If the exception handling container determines that the second execution result is an execution exception, it will report the exception to the runtime environment that called the exception handling container, exit the current exception handling container, and wake up the suspended first virtual machine.

[0103] The runtime environment of the exception handling container can be understood as the system environment where the first virtual machine resides. It is responsible for identifying the presence of a higher-level exception handling container. If not, it exits the first virtual machine and terminates the program; if so, it returns to the higher-level exception handling container to execute subsequent container logic code. The reported exception can include the exception type or exception data. Through this configuration, exceptions detected by the exception handling container can be correctly reported to the higher-level program code that called the exception handling container (e.g., the higher-level exception handling container itself), allowing the higher-level program code to respond accurately and appropriately based on the exception.

[0104] Understandably, in the absence of nested exception handler calls, if an exception handling container detects an exception by executing a second function, it indicates an error has occurred during program execution. In this case, no further bytecode will be executed; only the exception will be reported. However, if the currently called exception handler is nested within another parent exception handling container, the exception detected by the currently called exception handler might only be an intermediate result used by the parent exception handling container. The parent exception handling container might need to execute other logic code to determine whether its final detection result is normal or abnormal. In this case, the exception detected by the current exception handling container needs to be reported back to the parent exception handling container so that the parent exception handling container can continue executing subsequent container logic code.

[0105] The second execution result can be either normal or abnormal. When the second execution result is normal, it indicates that the second function successfully handled the exception generated during the execution of the first function. In this case, the second virtual machine can exit, wake up the first virtual machine, and execute subsequent bytecode. When the second execution result is abnormal, the exception is reported back to the runtime environment that called the exception handling container. After exiting the second virtual machine, the first virtual machine is woken up to check if an upper-level exception handling container exists. If not, the first virtual machine exits and the program terminates; if so, it returns to the upper-level exception handling container to execute subsequent container logic code. This process ensures that the exception handling container can effectively monitor and handle exceptions, maintaining the stability and reliability of program execution.

[0106] The technical solution of this invention, by simultaneously encapsulating the execution logic of the first function and the second function in the exception handling container, can realize the exception handling logic based on the try-catch block in the prior art through system interface calls. While effectively reducing the occupation of storage space, especially non-volatile storage space, it can efficiently, conveniently and accurately realize exception handling of WebAssembly applications.

[0107] Based on the above embodiments, at least one parameter also includes a fourth parameter, which is used to locate the second parameter array, which contains various parameters required during the execution of the second function.

[0108] Accordingly, after locating the second function corresponding to the third parameter through the exception handling container, starting and using the second virtual machine to execute the second function may include:

[0109] The exception handling container locates the second function corresponding to the third parameter, locates and obtains the second parameter array corresponding to the fourth parameter, starts and uses the second virtual machine, and executes the second function based on the second parameter array.

[0110] For example, the exception handling container is defined as `u32 exceptionProcess(void*tryBlock, u32*tryParam, void*catchBlock, u32*catchParam)`. The logic code that needs to monitor exceptions is used as the first function `tryBlock`, and the parameters of the first function are stored in the first parameter array `tryParam[]`. The logic code that handles exceptions is used as the second function `catchBlock`. If the exception handling block function has parameters, the parameters of the second function are stored in the second parameter array `catchParam[]`.

[0111] When the first virtual machine executes bytecode of the form "If(exceptionProcess(&tryBlock,tryParam,&catchBlock,catchParam)==OK){}", it calls the exception handling container, suspends the first virtual machine, and passes the first, second, third, and fourth parameters to the exception handling container. The exception handling container locates the first function `tryBlock` corresponding to the first parameter and locates and obtains the first parameter array `tryParam` corresponding to the second parameter. It then starts and uses the second virtual machine to execute the code in the `tryBlock` function using the parameters in the `tryParam` array. After obtaining the first execution result of the first function, the exception handling container exits. If the first execution result is normal execution, the exception handling container exits and wakes up the first virtual machine to execute the subsequent processing flow. If the first execution result is an execution exception, the exception handling container locates the second function `catchBlock` corresponding to the third parameter and locates and obtains the second parameter array `catchParam` corresponding to the fourth parameter. It then restarts the second virtual machine to execute the code in the `catchBlock` function using the parameters in the `catchParam` array. The exception handling container obtains the second execution result of the second function. If the second execution result is normal, the exception handling container exits and the first virtual machine is woken up to continue executing subsequent bytecode. If the second execution result is abnormal, the exception can be reported back to the runtime environment that called the exception handling container. After exiting the second virtual machine, the first virtual machine is woken up to check if there is an upper-level exception handling container. If not, the first virtual machine exits and the program ends. If so, it returns to the upper-level exception handling container to execute subsequent container logic code.

[0112] Based on the above embodiments, after locating and obtaining the first parameter array corresponding to the second parameter through the exception handling container, the method may further include:

[0113] The exception handling container uses the top of the stack pointed to by the stack pointer of the currently suspended first virtual machine as the stack bottom, and pushes each parameter in the first parameter array onto the virtual machine stack so that the first function can use each parameter in the first parameter array during execution.

[0114] Accordingly, after locating and obtaining the second parameter array corresponding to the fourth parameter through the exception handling container, it may also include:

[0115] The exception handling container pushes the parameters in the second parameter array onto the virtual machine stack, using the top of the stack pointed to by the virtual machine stack pointer of the currently suspended first virtual machine as the stack bottom, so that the second function can use the parameters in the second parameter array during execution.

[0116] In this embodiment, the virtual machine adopts a stack-based structure. The virtual machine stack is used to store stack frames, including storing parameters, local variables, intermediate execution results, return values, and method call information.

[0117] Specifically, the exception handling container uses the top of the stack pointer of the currently suspended first virtual machine as the stack bottom. Parameters from the first and second parameter arrays are pushed onto the virtual machine stack respectively, for use by the first and second functions. Using the top of the suspended virtual machine's stack pointer as the bottom of the new virtual machine ensures data consistency. All previous operations and data are preserved, avoiding data loss or state inconsistencies when waking up the first virtual machine. Virtual machines share the same stack space, improving memory resource utilization efficiency, avoiding the need to allocate independent stack space for each virtual machine, and avoiding the need to allocate additional cache stacks in the volatile storage area when exception handling is nested. This solves the problem of nesting levels being limited by cache stack capacity and saves volatile storage space.

[0118] Because the new virtual machine uses the stack of the suspended virtual machine, there is no need to reallocate and initialize the stack space when switching virtual machine runtime domains, which simplifies the virtual machine runtime domain switching process and improves the efficiency and reliability of exception handling during application runtime.

[0119] Optionally, the first parameter array or the second parameter array is a temporary array; the first array element in the first parameter array or the second parameter array is used to record the number of parameters.

[0120] Specifically, the temporary array can be used as the first or second parameter array. The temporary array can act as a buffer, reducing frequent memory allocation and release operations. The first element of the temporary array is used to record the number of parameters, which simplifies the processing logic of the array. The remaining virtual machine stack space can be calculated based on the number of parameters, allowing for more efficient use of memory and improving the reliability of exception handling during application runtime.

[0121] Optionally, the exception handling container is a system-level application programming interface provided by the runtime environment, and the first, second, third, and fourth parameters are pointer types.

[0122] Specifically, an exception handling container is established as an application programming interface (API). Through the interface, different types of exceptions are centrally managed and handled, improving exception handling efficiency. The first, second, third, and fourth parameters are pointer parameters, which can dynamically point to different data at runtime. This provides the interface with more operation options and allows functions to directly access and modify variables provided by the caller without copying data, thus improving the efficiency of data operations.

[0123] Figure 3 is a flowchart of another exception handling method for application runtime provided by an embodiment of the present invention. This embodiment refines the above embodiments and specifically specifies the exception handling operation when nested call exception handlers occur.

[0124] In this embodiment, a three-level nested exception handler is used as an example. Specifically, a three-level nested exception handler may include: an upper-level exception handler, a current exception handler, and a lower-level exception handler. The current exception handler is nested within the upper-level exception handler, and the lower-level exception handler is nested within the current exception handler. For clarity, this embodiment uses independent virtual machines to execute the functions called within each exception handler. Specifically, a first virtual machine executes the functions called by the upper-level exception handler, a second virtual machine executes the functions called by the current exception handler, and a third virtual machine executes the functions called by the lower-level exception handler.

[0125] Accordingly, as shown in Figure 3, the method includes nested calls to the exception handling container during its execution:

[0126] S310. Start and use the first virtual machine through the upper-layer exception handling container to execute the bytecode in the third or fourth function.

[0127] The upper-level processing container encapsulates calls to the third and / or fourth functions. The third function consists of logic code that the upper-level exception handling container needs to monitor for exceptions, and the fourth function consists of logic code that needs to be executed after an exception occurs during the execution of the third function.

[0128] In this embodiment, the current exception handling container is nested within the third or fourth function of the upper-level handling container.

[0129] That is, in this embodiment, the current exception handling container can be nested into the tryBlock function or the catchBlock function executed by the upper-level exception handling container.

[0130] S320. During the execution of bytecode using the first virtual machine, in response to the call to the current exception handling container, suspend the first virtual machine and pass at least one parameter to the current exception handling container.

[0131] The current exception handling container encapsulates calls to a first function and / or a second function. The first function consists of logic code that the current exception handling container needs to monitor for exceptions, and the second function consists of logic code that needs to be executed after an exception occurs during the execution of the first function.

[0132] S330. Start and use the second virtual machine through the current exception handling container to execute the bytecode in the first or second function.

[0133] In an optional implementation of this embodiment, a lower-level exception handling container is nested within the first or second function executed by the exception handling container.

[0134] S340. During the execution of bytecode using the second virtual machine, in response to a call to the lower-level exception handling container, the second virtual machine is suspended, and at least one parameter is passed to the lower-level exception handling container.

[0135] The lower-level exception handling container encapsulates calls to the fifth function and / or the sixth function. The fifth function consists of the logic code that the lower-level exception handling container needs to monitor for exceptions, and the sixth function consists of the logic code to be executed when an exception occurs during the execution of the fifth function.

[0136] S350: Starts and uses a third virtual machine through a lower-level exception handling container to execute bytecode in the fifth or sixth function.

[0137] It is understandable that during exception handling at runtime, nested exception handling containers are executed sequentially in the order they are called, and exit sequentially in the reverse order of the call sequence.

[0138] Furthermore, after a lower-level exception handling container completes execution and generates an exception, it can report the exception to the runtime environment of the current exception handling container, allowing the current exception handling container to continue executing its internally defined code logic based on the exception. Similarly, after the current exception handling container completes execution and generates an exception, it can report the exception to the runtime environment of the upper-level exception handling container, allowing the upper-level exception handling container to continue executing its internally defined code logic based on the exception.

[0139] In this embodiment of the invention, each exception handling container can have an upper-level exception handling container and / or a lower-level exception handling container. If, during the execution of the current exception handling container, its lower-level exception handling container is called to handle an exception, the nested exception handling containers will execute their exception handling tasks step by step according to the order in which they are activated, i.e., the call order. When the exception is successfully handled, or when the upper-level exception handling container needs to handle the exception, the current exception handling container will enter an exit process. This exit process is performed in the reverse order of the call order, i.e., the exception handling container that entered last exits first. Before exiting, each exception handling container will perform necessary work, such as exiting the current virtual machine and waking up the upper-level virtual machine, and restoring various runtime state information in the upper-level virtual machine's runtime environment according to records. Finally, when all relevant exception handling containers have completed their tasks and exited, the application will return to a safe or stable state, or, depending on the nature of the exception and the handling result, it will be determined whether the application needs to be restarted or terminated. This orderly execution and exit mechanism ensures the transparency and controllability of nested exception handling, while also reducing the consumption of system resources, improving the overall response speed of the application to abnormal situations, and enhancing the reliability of exception handling.

[0140] Specific application scenarios

[0141] Figure 4 is a schematic diagram of a specific application scenario to which the embodiments of the present invention are applicable. In this specific application scenario, in order to avoid the various troubles that the introduction of exception handling mechanism would bring to the runtime environment of the resource-constrained embedded operating system running WebAssembly applications, the embodiments of the present invention design a novel exception handling container. The runtime environment provides container interface processing capabilities, and the code blocks that need to monitor exceptions and the code blocks that handle exceptions after they occur are represented in the form of functions, and these functions are placed in the exception handling container for execution.

[0142] Accordingly, as shown in Figure 4, the method for handling this exception is described as follows:

[0143] 1. A code block function is a block of code that needs to monitor exceptions. It is represented as a function, similar to the code within a try{} block in a programming language that supports exception keywords. Exception handling containers can be nested within this code block function.

[0144] 2. An exception handling block function is a block of code used to handle exceptions after they occur. It is represented as a function, similar to the code within `catch{}` and / or `finally{}` blocks in programming languages ​​that support exception keywords. Exception handling containers can be nested within this block function.

[0145] 3. The exception handling container is a system interface provided by the runtime environment. It is used to execute code block functions and exception handling functions. The function indexes of the code block functions and exception handling functions are passed into the exception handling container. If the code block functions and exception handling functions have their own parameters, the parameters must also be passed into the exception handling container.

[0146] 4. Before the exception handling container executes the code block function, it suspends the currently running virtual machine and records its runtime information (program counter, stack pointer, etc.) in temporary variables (allocated in the operating system's runtime stack). Using the top of the stack pointed to by the current virtual machine's runtime stack pointer as the stack bottom, a new virtual machine is started to execute the code block function. If an exception occurs during the execution of the code block function, the new virtual machine exits. If an exception handling code block exists, the aforementioned new virtual machine is started again to execute the exception handling code block function. If no exception occurs during the execution of the code block function, the exception handling container exits. Upon exiting the exception handling container, the virtual machine information recorded in the temporary variables is restored, and the suspended virtual machine is awakened.

[0147] In one optional implementation, the exception handling container is described as follows:

[0148] 1. Container Definition

[0149] The exception handling container is a system interface provided by the runtime environment. An example definition is `u32exceptionProcess(void*tryBlock, u32*tryParam, void*catchBlock, u32*catchParam)`. When writing an application, the logic code that needs to monitor exceptions is placed in a function (such as the function `tryBlock`), i.e., the code block function mentioned above. If the code block function needs parameters, a temporary array is used to store the parameters (such as the array `tryParam[]`). The logic code that handles exceptions is placed in a function (such as the function `catchBlock`), i.e., the exception handling code block mentioned above. If the exception handling code block function has parameters, a temporary array is used to store the parameters (such as the array `catchParam[]`).

[0150] 2. Instructions for use

[0151] In a specific example, when an application calls an exception handling container to execute code that needs to monitor and handle exceptions, it calls code of the following form:

[0152] "If(exceptionProcess(&tryBlock,tryParam,&catchBlock,catchParam)==OK){}".

[0153] 3. Operational Logic

[0154] The exception handling container is responsible for executing the code in the tryBlock function using the parameters in the tryParam array. If an exception occurs in the tryBlock function, the exception handling container is responsible for executing the code in the catchBlock function using the parameters in the catchParam array. If no exception occurs, the exception handling container exits. If the catchBlock does not exist, the exception is considered to be unhandled. If the catchBlock exists and an exception occurs during its execution, the exception is handed over to the runtime environment of the calling container for handling.

[0155] Furthermore, the exception handling execution process of the exception handling container is described as follows:

[0156] The exception handling execution process is the running process of the exception handling container. Taking the current runtime environment calling the exception handling container interface as an example, the specific steps are as follows:

[0157] 1) Suspend the currently running virtual machine, including using temporary variables to record key data such as the program counter and stack pointer in the current virtual machine runtime environment.

[0158] 2) Using the top of the stack pointed to by the stack pointer of the currently running virtual machine as the stack bottom, push the parameters in the parameter array tryParam of the tryBlock function onto the stack, where tryParam[0] records the number of parameters.

[0159] 3) Find the index of the tryBlock function based on the &tryBlock parameter, find the address of the function bytecode, tryBlockAddr, set the virtual machine's program counter to tryBlockAddr, and start the virtual machine to execute the bytecode at the tryBlockAddr address.

[0160] 4) If no exception occurs and the virtual machine exits during the execution of the tryBlock function, proceed to step 8); otherwise, proceed to step 5.

[0161] 5) If the `catchBlock` function exists (and `&catchBlock` is not empty), then the index of the `catchBlock` function is found based on the `&catchBlock` parameter. The address of the function's bytecode, `catchBlockAddr`, is then located based on the function index. Using the top of the currently running virtual machine's stack pointer as the stack bottom, the parameters in the `catchParam` array are pushed onto the stack, and the virtual machine is started to execute the bytecode at the address `catchBlockAddr`. If the `catchBlock` function does not exist, the current exception is considered unnecessary to handle, and the exception information is cleared.

[0162] 6) If the catchBlock function completes execution without any exception, proceed to step 8); otherwise, proceed to step 7.

[0163] 7) If an exception occurs, retrieve the exception type and data from the generated exception, hand the exception over to the runtime environment of the recovered exception handling container, and re-execute the suspended virtual machine.

[0164] The runtime environment of the exception handling container identifies whether an upper-level exception handling container exists. If not, the virtual machine exits and the program ends. If it does, the program returns to the upper-level exception handling container to execute subsequent container logic code.

[0165] 8) Recover the critical data required to run the virtual machine from the temporary variables that record virtual machine runtime information, wake up and run the virtual machine. If there is an exception, throw an exception. Otherwise, proceed to step 9).

[0166] 9) Return the results of the exception handling container operation.

[0167] Furthermore, the process of handling nested exceptions is described as follows:

[0168] Exception nesting occurs during the execution of the `tryBlock` and `catchBlock` functions. This means that the exception handling container's interface is called within these two functions. Each call follows the exception handling execution process described above. Specifically, when a nested call to the exception handling container occurs during steps 3) and 5), the currently running virtual machine and runtime environment are suspended, and execution resumes from step 1). Once the nested exception is handled, the suspended virtual machine and runtime environment are awakened, and execution continues with the subsequent steps of steps 3) and 5).

[0169] The nested exception handling process is executed in the order in which the exception handling container is called, and exits in reverse order when the call ends.

[0170] In the specific application scenarios provided in the embodiments of the present invention, by implementing an exception handling container in the runtime environment and executing the code that needs to monitor and handle exceptions in the exception handling container, the following beneficial effects can be achieved:

[0171] 1. Avoiding the need to allocate additional cache stacks in the volatile storage area when exception handling is nested not only solves the problem of nesting levels being limited by cache stack capacity, but also saves volatile storage space.

[0172] 2. Avoid generating and recording exception handling information when generating bytecode, thus saving application storage space.

[0173] 3. By using function representation when compiling the source code, the problem of exception handling information not being generated when the optimization level is high is avoided.

[0174] 4. No need to extend virtual machine bytecode to implement exception handling.

[0175] Figure 5 is a structural diagram of an exception handling device for application runtime provided in an embodiment of the present invention. As shown in Figure 5, the device specifically includes: an exception handling container invocation module 510, an exception handling container execution module 520, and a processing flow execution module 530.

[0176] The exception handling container invocation module 510 is used to suspend the first virtual machine in response to a call to the exception handling container during the execution of bytecode using the first virtual machine, and to pass at least one parameter to the exception handling container. The at least one parameter includes a first parameter, which is used to locate a first function containing logic code that needs to monitor exceptions.

[0177] The exception handling container execution module 520 is used to execute the exception handling container, and after locating the first function corresponding to the first parameter through the exception handling container, it starts and uses the second virtual machine to execute the first function.

[0178] The processing flow execution module 530 is used to exit the second virtual machine and execute a processing flow that matches the first execution result when the exception handling container obtains the first execution result of the first function.

[0179] The technical solution of this invention, in response to a call to an exception handling container during the execution of bytecode using a first virtual machine, suspends the first virtual machine and passes a parameter containing a first parameter to the exception handling container; executes the exception handling container, locates the first function corresponding to the first parameter through the exception handling container, starts and uses a second virtual machine to execute the first function; and when the exception handling container obtains the first execution result of the first function, exits the second virtual machine and executes a processing flow matching the first execution result. Compared with the exception handling implementation method of defining special identifiers as conditional statements in the code, this invention encapsulates the logic code that needs to monitor exceptions in the form of a function in the exception handling container. This avoids the situation where the bytecode conversion tool optimizes the content before and after the conditional statements when the optimization level is high, thus causing the exception handling function to fail. This improves the reliability of exception handling. In addition, the implementation method of this invention can effectively avoid generating too much exception handling information, thereby effectively reducing the occupation of storage space. It is particularly suitable for runtime exception handling of WebAssembly applications running on resource-constrained devices.

[0180] Based on the above embodiments, at least one parameter further includes a second parameter, which is used to locate the first parameter array, which contains various parameters required during the execution of the first function.

[0181] Exception handling container execution module 520, specifically used for:

[0182] The exception handling container is used to locate the first function corresponding to the first parameter, and the array of first parameters corresponding to the second parameter is located and obtained.

[0183] The first function is executed based on the first parameter array by starting a second virtual machine through an exception handling container.

[0184] Based on the above embodiments, the processing flow execution module 530 is specifically used for:

[0185] If the exception handling container determines that at least one parameter contains only the first parameter, it exits the exception handling container directly and wakes up the first suspended virtual machine.

[0186] Based on the above embodiments, the process execution module 530 is further configured to:

[0187] If the exception handling container determines that at least one parameter contains only the first and second parameters, it exits the exception handling container directly and wakes up the suspended first virtual machine.

[0188] Based on the above embodiments, at least one parameter also includes a third parameter, which is used to locate the second function, which contains the logic code to be executed after an exception occurs during the execution of the first function.

[0189] Processing flow execution module 530 is further used for:

[0190] If the exception handling container determines that the first execution result is an execution exception, it locates the second function corresponding to the third parameter, starts and uses the second virtual machine to execute the second function.

[0191] When the exception handling container obtains the second execution result of the second function, it exits the second virtual machine and executes a processing flow that matches the second execution result.

[0192] Based on the above embodiments, the process execution module 530 is further configured to:

[0193] If the exception handling container determines that the first execution result is normal, it exits the exception handling container directly and wakes up the first suspended virtual machine.

[0194] Based on the above embodiments, the process execution module 530 is further configured to:

[0195] If the exception handling container determines that the second execution result is normal, it exits the exception handling container directly and wakes up the suspended first virtual machine.

[0196] If the exception handling container determines that the second execution result is an execution exception, it will report the exception to the runtime environment that called the exception handling container, exit the current exception handling container, wake up the suspended first virtual machine, and check whether there is an upper-level exception handling container. If not, it will exit the first virtual machine and end the program execution. If so, it will return to the upper-level exception handling container to execute the subsequent container logic code.

[0197] Based on the above embodiments, at least one parameter also includes a fourth parameter, which is used to locate the second parameter array, which contains various parameters required during the execution of the second function.

[0198] Accordingly, the exception handling container execution module 520 is further used for:

[0199] The exception handling container is used to locate the second function corresponding to the third parameter, and the array of the second parameters corresponding to the fourth parameter is located and obtained.

[0200] A second virtual machine is started and used through an exception handling container, and a second function is executed based on a second parameter array.

[0201] Based on the above embodiments, the exception handling container calling module 510 is further specifically used for:

[0202] The exception handling container records various runtime status information in the first virtual machine runtime environment, including the program counter and the virtual machine stack pointer.

[0203] Accordingly, the process execution module 530 is further used for:

[0204] The exception handling container restores the runtime state information required to run the first virtual machine based on the recorded results.

[0205] Based on the above embodiments, the exception handling container invocation module 510 is further configured to:

[0206] The exception handling container uses temporary variables to record various runtime state information in the first virtual machine runtime environment. These temporary variables are dynamically stored in the operating system's runtime stack.

[0207] Based on the above embodiments, the exception handling container execution module 520 is further configured to:

[0208] The exception handling container uses the top of the stack pointed to by the stack pointer of the currently suspended first virtual machine as the stack bottom, and pushes each parameter in the first parameter array onto the virtual machine stack so that the first function can use each parameter in the first parameter array during execution.

[0209] The exception handling container pushes the parameters in the second parameter array onto the virtual machine stack, using the top of the stack pointed to by the virtual machine stack pointer of the currently suspended first virtual machine as the stack bottom, so that the second function can use the parameters in the second parameter array during execution.

[0210] Based on the above embodiments, the bytecode executed by the first virtual machine includes: bytecode in any function executed by the upper-level exception handling container of the exception handling container;

[0211] The exception handling container is nested within any function executed by the upper-level exception handling container. The functions executed by the upper-level exception handling container include a third function consisting of logic code that needs to monitor exceptions, and / or a fourth function consisting of logic code that needs to be executed after an exception occurs during the execution of the third function.

[0212] Based on the above embodiments, a lower-level exception handling container is nested in the first or second function executed by the exception handling container.

[0213] Based on the above embodiments, the exception handling container execution module 520 is further configured to:

[0214] During exception handling at runtime, nested exception handling containers are executed sequentially in the order they are called, and exit sequentially in the reverse order of the call sequence.

[0215] Based on the above embodiments, the first parameter array or the second parameter array is a temporary array. The first array element in the first parameter array or the second parameter array is used to record the number of parameters.

[0216] Based on the above embodiments, the exception handling container is a system-level application programming interface provided by the runtime environment, and the first parameter, the second parameter, the third parameter and the fourth parameter are pointer type.

[0217] The exception handling device for application runtime provided in the embodiments of the present invention can execute the exception handling method for application runtime provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0218] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0219] Figure 6 shows a schematic diagram of the structure of a limited device 10 that can be used to implement embodiments of the present invention. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the invention described and / or claimed herein.

[0220] As shown in Figure 6, the restricted device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the restricted device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0221] The I / O interface 15 in the restricted device 10 may include eSPI (Enhanced Serial Peripheral Interface) and SPI (Serial Peripheral Interface), etc.

[0222] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, for example, performing an exception handling method for application runtime as described in various embodiments of the present invention, executed by a runtime environment in an embedded operating system installed in a restricted device, the method comprising:

[0223] During the execution of bytecode using the first virtual machine, in response to a call to the exception handling container, the first virtual machine is suspended, and at least one parameter is passed to the exception handling container. Among these parameters, at least one parameter includes a first parameter, which is used to locate the first function. The first function contains logic code that needs to monitor exceptions. The exception handling container is executed, and after locating the first function corresponding to the first parameter through the exception handling container, the second virtual machine is started and used to execute the first function. When the exception handling container obtains the first execution result of the first function, the second virtual machine exits and executes a processing flow that matches the first execution result.

[0224] In some embodiments, the exception handling method for application runtime may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 16. In some embodiments, part or all of the computer program may be loaded and / or installed on the restricted device 10 via ROM 12. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the exception handling method for application runtime as described above in the embodiments of the present invention may be performed. Alternatively, in other embodiments, processor 11 may be configured by any other suitable means (e.g., by means of firmware) to perform the exception handling method for application runtime as described in the embodiments of the present invention.

[0225] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0226] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0227] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0228] Figure 7 is a structural diagram of a terminal according to an embodiment of the present invention. As shown in Figure 7, the terminal includes a restricted device 710 as described in any embodiment of the present invention.

[0229] The restricted device can be understood as a resource-restricted device, which can typically be a smart card, USB key, ESAM (Embedded Secure Access Module), or SE (Secure Element), etc. The smart card in question is generally a multi-application smart card.

[0230] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0231] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for handling exceptions during application runtime, characterized in that, include: During the execution of WebAssembly bytecode using the first virtual machine, in response to a call to the exception handling container, the first virtual machine is suspended, and at least one parameter is passed to the exception handling container. This parameter includes a first parameter, which is used to locate the first function, which contains logic code that needs to monitor exceptions. The exception handling container is executed, and after locating the first function corresponding to the first parameter, the second virtual machine is started and used to execute the first function. When the exception handling container obtains the first execution result of the first function, the second virtual machine exits and executes a processing flow matching the first execution result.

2. The method according to claim 1, characterized in that, At least one parameter also includes a second parameter, which is used to locate the first parameter array. The first parameter array contains all the parameters required during the execution of the first function. After locating the first function corresponding to the first parameter through the exception handling container, the second virtual machine is started and used to execute the first function, including: locating the first function corresponding to the first parameter through the exception handling container, locating and obtaining the first parameter array corresponding to the second parameter; starting and using the second virtual machine through the exception handling container, and executing the first function based on the first parameter array.

3. The method according to claim 1, characterized in that, The exception handling container executes a processing flow that matches the first execution result, including: if the exception handling container determines that at least one parameter contains only the first parameter, it directly exits the exception handling container and wakes up the suspended first virtual machine.

4. The method according to claim 2, characterized in that, The exception handling container executes a processing flow that matches the first execution result, including: if the exception handling container determines that at least one parameter contains only the first parameter and the second parameter, it directly exits the exception handling container and wakes up the suspended first virtual machine.

5. The method according to claim 1, characterized in that, At least one parameter also includes a third parameter, which is used to locate the second function, which contains the logic code to be executed after an exception occurs during the execution of the first function; The exception handling container executes a processing flow that matches the first execution result, including: if the exception handling container determines that the first execution result is an execution exception, it locates the second function corresponding to the third parameter, starts and uses the second virtual machine to execute the second function; when the exception handling container obtains the second execution result of the second function, it exits the second virtual machine and executes a processing flow that matches the second execution result.

6. The method according to claim 5, characterized in that, The process of executing a process matching the first execution result through the exception handling container also includes: if the exception handling container determines that the first execution result is normal, it directly exits the exception handling container and wakes up the suspended first virtual machine.

7. The method according to claim 5, characterized in that, The process of executing a matching flow with the second execution result through the exception handling container includes: if the exception handling container determines that the second execution result is normal, it directly exits the exception handling container and wakes up the suspended first virtual machine; if the exception handling container determines that the second execution result is an execution exception, it feeds back the exception to the runtime environment that called the exception handling container, exits the current exception handling container, and wakes up the suspended first virtual machine. The runtime environment that called the exception handling container identifies whether there is an upper-level exception handling container. If not, it exits the first virtual machine and ends the program execution. If so, it returns to the upper-level exception handling container to execute the subsequent container logic code.

8. The method according to claim 5, characterized in that, At least one parameter also includes a fourth parameter, which is used to locate the second parameter array. The second parameter array contains all the parameters required during the execution of the second function. After locating the second function corresponding to the third parameter through the exception handling container, the second virtual machine is started and used to execute the second function, including: locating the second function corresponding to the third parameter through the exception handling container, locating and obtaining the second parameter array corresponding to the fourth parameter; starting and using the second virtual machine through the exception handling container, and executing the second function based on the second parameter array.

9. The method according to any one of claims 1-8, characterized in that, Suspending the first virtual machine via the exception handling container further includes: recording various runtime state information of the first virtual machine runtime environment via the exception handling container, wherein the runtime state information includes the program counter and the virtual machine stack pointer; waking up the suspended first virtual machine via the exception handling container further includes: restoring the runtime state information required to run the first virtual machine based on the recorded results via the exception handling container.

10. The method according to claim 9, characterized in that, The exception handling container records various runtime status information in the first virtual machine runtime environment, including: using temporary variables to record various runtime status information in the first virtual machine runtime environment; wherein, the temporary variables are dynamically stored in the operating system's runtime stack.

11. The method according to claim 9 or 10, characterized in that, After locating and obtaining the first parameter array corresponding to the second parameter through the exception handling container, the method further includes: using the exception handling container with the top of the stack pointed to by the virtual machine stack pointer of the currently suspended first virtual machine as the stack bottom, pushing each parameter in the first parameter array onto the virtual machine stack, so that the first function can use each parameter in the first parameter array during execution; after locating and obtaining the second parameter array corresponding to the fourth parameter through the exception handling container, the method further includes: using the exception handling container with the top of the stack pointed to by the virtual machine stack pointer of the currently suspended first virtual machine as the stack bottom, pushing each parameter in the second parameter array onto the virtual machine stack, so that the second function can use each parameter in the second parameter array during execution.

12. The method according to any one of claims 1-8, characterized in that, The WebAssembly bytecode executed using the first virtual machine includes: WebAssembly bytecode in any function executed by the upper-level exception handling container of the exception handling container; wherein, the exception handling container is nested in any function executed by the upper-level exception handling container, and the function executed by the upper-level exception handling container includes a third function consisting of logic code that needs to monitor exceptions, and / or a fourth function consisting of logic code that needs to be executed after an exception is generated during the execution of the third function.

13. The method according to any one of claims 1-8, characterized in that, Within the first or second function executed by the exception handling container, there is a nested lower-level exception handling container.

14. The method according to claim 12, characterized in that, During exception handling at runtime, nested exception handling containers are executed sequentially in the order they are called, and exit sequentially in the reverse order of the call sequence.

15. The method according to claim 2 or 8, characterized in that, The first or second parameter array is a temporary array; the first element of the first or second parameter array is used to record the number of parameters.

16. The method according to any one of claims 1-8, characterized in that, The exception handling container is a system-level application programming interface provided by the runtime environment. The first, second, third, and fourth parameters are pointer types.

17. An exception handling device for application runtime, characterized in that, A runtime environment configured within an embedded operating system, which is installed in a restricted device, includes: an exception handling container invocation module, configured to, in response to an invocation of an exception handling container during the execution of WebAssembly bytecode using a first virtual machine, suspend the first virtual machine and pass at least one parameter to the exception handling container; wherein the at least one parameter includes a first parameter, which is used to locate a first function, and the first function contains logic code that needs to monitor exceptions; an exception handling container execution module, configured to execute the exception handling container, and after locating the first function corresponding to the first parameter through the exception handling container, start and use a second virtual machine to execute the first function; and a first execution result execution module, configured to, when the exception handling container obtains the first execution result of the first function, exit the second virtual machine and execute a processing flow matching the first execution result.

18. A restricted device, characterized in that, The restricted device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform an exception handling method for the application runtime as described in any one of claims 1-16.

19. A terminal, characterized in that, Including the restricted device as described in claim 18.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the exception handling method for the application program as described in any one of claims 1-16.

21. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the exception handling method for the application runtime according to any one of claims 1-16.

Images