An instruction execution system, method, device and medium

Abstract

The application discloses an instruction execution system, method, device and medium for realizing batch instruction flow communication between JS and Wasm. The method comprises the following steps: writing at least one instruction set into an instruction area of a preset shared memory through a JS engine, and writing data required by the instruction into a data area of the shared memory; wherein each instruction set comprises at least one instruction; the instruction is a binary instruction; acquiring the instruction set from the instruction area of the shared memory through a Wasm engine, and performing analysis on each instruction set according to a preset instruction set format, and performing analysis on each instruction in each instruction set according to a preset instruction format to obtain each instruction; acquiring the data required by each instruction from the data area of the shared memory, and based on the data required by the instruction, calling an algorithm corresponding to the instruction according to a preset mapping relationship between the instruction and the algorithm, executing the instruction, and storing an execution result into a result area of the shared memory.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an instruction execution system, method, device and medium. Background Technology

[0002] WebAssembly (Wasm for short) is a low-level binary instruction format that can be used as a compilation target for high-level languages ​​(such as C / C++, Rust) and executed efficiently in a browser (or server-side), aiming to provide near-native performance. In other words, WebAssembly, as a binary instruction execution technology that can achieve near-native performance in a browser, brings high-performance computing capabilities to front-end applications, especially suitable for computationally intensive scenarios such as encryption / decryption, graphics rendering, and data analysis. Summary of the Invention

[0003] This application provides an instruction execution system, method, device, and medium to enable communication of batch instruction streams between JS and Wasm, thereby improving instruction execution efficiency.

[0004] This application provides an instruction execution system, comprising: a JS engine, shared memory, and a Wasm engine; wherein, The JS engine is configured to: write at least one instruction set to the instruction area of ​​the shared memory; write the data required by the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; and the instruction is a binary instruction. The shared memory includes an instruction area, a data area, and a result area; wherein, the instruction area is used to store the set of instructions to be executed; the data area is used to store the data required by the instructions; and the result area is used to store the execution results returned by the Wasm engine. The Wasm engine is used to obtain instruction sets from the instruction area of ​​the shared memory, parse each instruction set according to a preset instruction set format, and parse each instruction in each instruction set according to a preset instruction format to obtain each instruction; for each instruction, it obtains the data required by the instruction from the data area of ​​the shared memory, and based on the data required by the instruction and according to the preset mapping relationship between instructions and algorithms, it calls the algorithm corresponding to the instruction, executes the instruction, and stores the execution result in the result area of ​​the shared memory.

[0005] As can be seen, in the instruction execution system provided in this application embodiment, the JS engine can write at least one instruction set to the instruction area of ​​the shared memory; and write the data required for the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; the instruction is a binary instruction; the shared memory includes an instruction area, a data area, and a result area; wherein the instruction area can store the instruction set to be executed; the data area can store the data required for the instruction; the result area can store the execution result returned by the Wasm engine; the Wasm engine can obtain the instruction set from the instruction area of ​​the shared memory, and parse each instruction set according to a preset instruction set format, and parse each instruction in each instruction set according to a preset instruction format to obtain each instruction; the Wasm engine can therefore obtain the data required for each instruction from the data area of ​​the shared memory, and based on the data required for the instruction and according to a preset mapping relationship between instructions and algorithms, call the algorithm corresponding to the instruction, execute the instruction, and store the execution result in the result area of ​​the shared memory. Therefore, the JS engine provided in this application embodiment can submit an instruction set containing multiple instructions with binary encoding to the shared memory at once. The Wasm engine can execute the instructions by reading the instructions and data in the instruction set in the shared memory according to the preset binary protocol mechanism, thereby realizing batch processing of binary instruction streams. This effectively reduces the overhead of instruction communication and instruction format conversion between JS and Wasm, and also achieves a systematic improvement in task processing efficiency, improving the performance experience in complex front-end scenarios such as high concurrency and large data volume processing.

[0006] In some implementations, the Wasm engine, when executing each instruction: For instructions that have no dependencies, they are assigned to different threads to achieve parallel execution; For instructions with dependencies, serial coordinated execution is achieved through a pipeline buffer.

[0007] In some implementations, the Wasm engine identifies instructions with no dependencies and instructions with dependencies by constructing a directed acyclic graph (DAG) based on the dependency tag field of instructions in the instruction set.

[0008] In some implementations, the data stored in the data area is TLV-encoded data.

[0009] In some implementations, the instruction set format is as follows: Instruction set ID, number of instructions, total length of instruction set, and individual instructions.

[0010] In some implementations, the instruction format is as follows: Dependency flags, opcodes, instruction parameter length, and parameter data; The dependency tag is used to indicate the dependency relationship between instructions.

[0011] In some implementations, the Wasm engine is also used for: If the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction will be loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading.

[0012] In some implementations, the Wasm engine is also used for: During the container initialization phase, the pre-instantiation of the preset core Wasm module is completed. The core Wasm module includes the first screen local instance module.

[0013] In some implementations, the JS engine is also used for: Before the container starts, for static modules whose usage frequency is greater than a preset value, it is checked whether there is a local instance. If not, the Wasm file is loaded online and instantiated locally. The static module includes a basic algorithm library.

[0014] In some implementations, the shared memory further includes a metadata area for storing the starting address and length of the instruction area, data area, and result area; The JS engine is also used to write instruction addresses and data addresses to the metadata area of ​​the shared memory; The Wasm engine is also used to read instruction addresses and data addresses from the metadata area.

[0015] An instruction execution method provided in this application includes: The JS engine writes at least one instruction set to the instruction area of ​​a preset shared memory and writes the data required for the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; the instruction is a binary instruction. The Wasm engine retrieves instruction sets from the instruction area of ​​the shared memory, parses each instruction set according to a preset instruction set format, and parses each instruction in each instruction set according to a preset instruction format to obtain each instruction. For each instruction, the required data is retrieved from the data area of ​​the shared memory, and based on the required data and the preset mapping relationship between instructions and algorithms, the corresponding algorithm is called to execute the instruction, and the execution result is stored in the result area of ​​the shared memory.

[0016] In some embodiments, the method further includes: The Wasm engine notifies the JS engine that the instruction execution is complete. The JS engine reads the instruction execution results from the result area of ​​the shared memory.

[0017] In some implementations, when executing each instruction via the Wasm engine: For instructions that have no dependencies, they are assigned to different threads to achieve parallel execution; For instructions with dependencies, serial coordinated execution is achieved through a pipeline buffer.

[0018] In some embodiments, the method further includes: If it is determined that the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction is loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading.

[0019] In some embodiments, the method further includes: During the container initialization phase, the pre-instantiation of the preset core Wasm module is completed. The core Wasm module includes the first screen local instance module.

[0020] In some embodiments, the method further includes: Before the container starts, for static modules whose usage frequency is greater than a preset value, it is checked whether there is a local instance. If not, the Wasm file is loaded online and instantiated locally. The static module includes a basic algorithm library.

[0021] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory is used to store program instructions, and the processor is used to call the program instructions stored in the memory and execute any of the methods described above according to the obtained program.

[0022] Another embodiment of this application provides a computer-readable storage medium storing computer-executable instructions for causing the computer to perform any of the methods described above. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1A schematic diagram of the compilation chain construction process of a WebAssembly module provided in this application embodiment; Figure 2 A schematic diagram of a general functional call interaction process between JS and Wasm provided in an embodiment of this application; Figure 3 This application provides a schematic diagram of a zero-copy data transfer interaction process between JS and Wasm in shared memory, as illustrated in an embodiment of the present application. Figure 4 A flowchart illustrating an instruction execution method provided in an embodiment of this application; Figure 5 A schematic diagram of an instruction execution system provided in an embodiment of this application; Figure 6 A schematic diagram of an atomic parallel engine based on the Wasm instruction set is provided in an embodiment of this application; Figure 7 A schematic diagram of the Wasm module loading and execution process provided in this application embodiment; Figure 8 This application provides a schematic diagram of a dynamic Wasm module loading and execution process. Figure 9 This application provides a schematic diagram of a shared memory space layout. Figure 10 A schematic diagram of an instruction set format provided for an embodiment of this application; Figure 11 A schematic diagram of an addition single instruction provided in an embodiment of this application; Figure 12 A schematic diagram of a binary design for an object data format provided in this application embodiment; Figure 13 This application provides a schematic diagram of a multi-task interaction process between JS and Wasm based on shared memory, as an embodiment of the present application. Figure 14 A schematic diagram of a Wasm atomization parsing instruction set provided in an embodiment of this application; Figure 15 This application provides an example flowchart of an engine parsing encrypted signature verification process. Figure 16 A schematic diagram illustrating the loading of a dynamically scalable module provided in an embodiment of this application; Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0026] This application provides an instruction execution system, method, device, and medium to enable communication of batch instruction streams between JS and Wasm, thereby improving instruction execution efficiency.

[0027] The systems, methods, devices, and media are based on the same application concept. Since the systems, methods, devices, and media solve problems in similar ways, their implementations can refer to each other, and repeated details will not be repeated.

[0028] The terms "first," "second," etc. (if present) in the specification, claims, and accompanying drawings of this application 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 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 a 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.

[0029] The following examples and embodiments are to be understood as illustrative only. While this specification may refer to "a," "an," or "some" examples or embodiments in several places, this does not mean that every such reference relates to the same example or embodiment, nor does it mean that the feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Furthermore, terms such as "comprising" and "including" should be understood not to limit the described embodiments to consisting only of those features mentioned; such examples and embodiments may also include features, structures, units, modules, etc., not specifically mentioned.

[0030] The various embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be noted that the order in which the embodiments are presented in this application represents only a chronological order and does not represent the superiority or inferiority of the technical solutions provided by the embodiments.

[0031] First, the following terms appearing in the embodiments of this application will be explained: wasm files: Raw file carriers that store WebAssembly binary code, with the .wasm extension.

[0032] wasm module: A collection of functions that can be called in a browser or WebView after a wasm file has been compiled and instantiated.

[0033] Core wasm module: The key module that supports the basic functions of the application. Its functions must be available immediately after the application starts, such as the core logic of page rendering and basic interaction processing tools.

[0034] Static modules: These are modules that are used frequently and whose content is stable over a long period of time. Typical examples include basic algorithm libraries and general utility function libraries. Therefore, it is suitable to complete pre-compilation and memory management in advance.

[0035] This application embodiment takes into account that Wasm technology may have the following performance bottlenecks in actual business implementation: 1. JavaScript (JS for short, a high-level programming language mainly used for web front-end interaction and is the core scripting language of web applications) and the data interaction mode between the module and the Wasm rely on frequent function calls, data copying and data format conversion. Whether it is text format or binary data transmission, there is a huge overhead caused by multiple communications, which seriously affects the efficiency of data transmission and processing. 2. The loading and instantiation process of the Wasm module in the browser is time-consuming, including steps such as network transmission of binary files, compilation and verification, and memory allocation, which can easily lead to page lag or response delay.

[0036] Furthermore, the compilation chain construction process of the WebAssembly module is as follows: Figure 1 As shown, the general functional call interaction flow between JS and Wasm is as follows: Figure 2 As shown, the zero-copy data transfer interaction process between JS and Wasm in shared memory is as follows: Figure 3 As shown. It is evident that if Wasm only engaged in basic communication with JS for batch data transfer and single instruction round trips, it cannot support batch instruction streams and atomic parallel execution. Specifically, the following problems exist: Communication and data entropy increase: JS and Wasm require multiple function call chains to complete a single function, with each interaction generating triple overhead: function call context switching, repeated read / write operations on shared memory, and cross-engine scheduling latency. Energy dissipation occurs when data is transferred between JS and Wasm, manifested as implicit type conversion and explicit serialization. CPU cycles intended for computation are ineffectively dissipated by communication scheduling and data conversion, and the more interactions occur, the higher the system disorder becomes, with scheduling energy consumption far exceeding computational energy consumption.

[0037] Resource idleness and dependency blocking: Wasm's single instruction round-trip mode cannot make full use of multi-core CPUs, resulting in a collapse in resource utilization. Instructions that have dependencies during communication (such as encryption → signing) must be executed completely serially. Even if the preceding task has produced 50% of the results, the subsequent task is still forced to wait, blocking the propagation of the dependency chain.

[0038] Loading and instantiation issues: When loading and instantiating the Wasm module in the main thread, compilation, verification, and memory allocation will block the main thread. If the module is large, the page will experience noticeable lag until instantiation is complete before it can respond to user operations.

[0039] Therefore, this application addresses the aforementioned problems encountered when using WebAssembly modules in browsers for practical business applications by proposing a WebAssembly communication scheme based on binary instruction stream batch processing. The aim is to build an efficient, low-latency, and scalable interaction system between JS and Wasm. By designing a three-layer collaborative mechanism involving the protocol layer, engine layer, and module management layer, the protocol layer optimizes communication efficiency, the engine layer enhances computing power, and the module management layer accelerates the loading process.

[0040] The three-layer collaborative mechanism of protocol layer, engine layer, and module management layer not only effectively reduces communication and conversion overhead and optimizes the interaction performance between JS and Wasm, but also achieves a systematic improvement in task processing efficiency, enhancing the performance experience in complex front-end scenarios such as high concurrency and large-scale data processing. Optimization of the module loading chain can significantly improve the first-screen response speed, providing a smoother user experience for high-performance front-end applications such as real-time audio and video, and 3D rendering.

[0041] See Figure 4 This application provides an instruction execution method, comprising: S101. Write at least one instruction set to the instruction area of ​​a preset shared memory using the JS engine, and write the data required for the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; the instruction is a binary instruction; The binary communication protocol-based interactive system provided in this application embodiment, for example Figure 5 As shown, it includes the JS engine, shared memory, and Wasm engine.

[0042] The JS engine has the following functions: Instruction set generation, data processing, data writing, function calls, data reading, etc.

[0043] Shared memory includes the following caching modules: Instruction area, data area, and result area.

[0044] The instruction area can store instruction set 1 to instruction set N, and each instruction set can include instruction 1 to instruction n. The data area is used to store usage data for instruction sets 1 to N; The result area is used to store the result data of instruction set 1 to instruction set N. The result data of each instruction set may include the result data of instruction 1 to instruction n.

[0045] The Wasm engine has the following functions: Instruction parsing, dynamic loading, instruction execution, data processing, and data writing, etc.

[0046] S102. Obtain instruction sets from the instruction area of ​​the shared memory using the Wasm engine, and parse each instruction set according to a preset instruction set format, and parse each instruction in each instruction set according to a preset instruction format to obtain each instruction; for each instruction, obtain the data required by the instruction from the data area of ​​the shared memory, and based on the data required by the instruction and according to the preset mapping relationship between instructions and algorithms, call the algorithm corresponding to the instruction, execute the instruction, and store the execution result in the result area of ​​the shared memory.

[0047] Therefore, the JS engine provided in this application embodiment can submit an instruction set containing multiple instructions with binary encoding to the shared memory at once. The Wasm engine can execute the instructions by reading the instructions and data in the instruction set in the shared memory according to the preset binary protocol mechanism, thereby realizing batch processing of binary instruction streams. This effectively reduces the overhead of instruction communication and instruction format conversion between JS and Wasm, and also achieves a systematic improvement in task processing efficiency, improving the performance experience in complex front-end scenarios such as high concurrency and large data volume processing.

[0048] Regarding the instruction stream batch processing communication protocol provided in the embodiments of this application: To achieve efficient communication between JS and Wasm, this application presents an instruction stream batch processing binary communication protocol. This protocol addresses three major pain points in Wasm communication: context switching overhead caused by high-frequency calls, CPU idle time caused by serialization, and cross-environment data format conversion costs, achieving a performance breakthrough of orders of magnitude through systemic architectural innovation.

[0049] The binary communication protocol specification provided in this application is shown in Table 1 below:

[0050] Table 1

[0051] As mentioned above, embodiments of this application provide an instruction interaction and execution system based on a binary communication protocol, for example... Figure 5As shown, it includes: a JS engine, shared memory, and a Wasm engine; among which, The JS engine is configured to: write at least one instruction set to the instruction area of ​​the shared memory; write the data required by the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; and the instruction is a binary instruction. The shared memory includes an instruction area, a data area, and a result area; wherein, the instruction area is used to store the set of instructions to be executed; the data area is used to store the data required by the instructions; and the result area is used to store the execution results returned by the Wasm engine. The Wasm engine is used to obtain instruction sets from the instruction area of ​​the shared memory, parse each instruction set according to a preset instruction set format, and parse each instruction in each instruction set according to a preset instruction format to obtain each instruction; for each instruction, it obtains the data required by the instruction from the data area of ​​the shared memory, and based on the data required by the instruction and according to the preset mapping relationship between instructions and algorithms, it calls the algorithm corresponding to the instruction, executes the instruction, and stores the execution result in the result area of ​​the shared memory.

[0052] As can be seen, the binary communication protocol provided in this application adopts a structured memory layout, batch instruction encoding, and a metadata self-description mechanism. It reconstructs the communication link through a shared memory three-zone architecture (instruction area / data area / result area), physically isolating and logically binding instructions and data to achieve low-cost data addressing and eliminate format conversion overhead. The JS engine compresses the frequently called JS and Wasm interactions into binary instruction sets, completing batch processing (e.g., instruction set 1...instruction set N) in a single submission, drastically reducing the number of communications and calls from N to 1. The instruction area has built-in self-interpreting data structures (e.g., instruction length, type flags), which are dynamically parsed by the Wasm engine without scheduling latency, ultimately significantly reducing the number of communications, lowering the CPU overhead of serialization, and reducing format conversion costs.

[0053] Wasm's linear memory byte stream model is compatible with binary encoding. The decoding process does not require a string or text intermediate state; it only reads bytes through pointer offsets, similar to "memory address jumps," resulting in extremely low CPU overhead. Binary data can be directly stored in shared memory (such as the instruction parameter area itself being in shared memory). During decoding, only the target memory address needs to be calculated (such as writing the parsed data to linear memory starting at 0x2000), without needing to copy from JS memory to Wasm memory—the data always resides in the same memory block; only the access pointers are adjusted.

[0054] In some implementations, the instruction set format is as follows: Instruction set ID, number of instructions, total length of instruction set, and individual instructions.

[0055] In some implementations, the instruction format is as follows: Dependency flags, opcodes, instruction parameter length, and parameter data; The dependency tag is used to indicate the dependency relationship between instructions.

[0056] In some implementations, the Wasm engine, when executing each instruction: For instructions that have no dependencies, they are assigned to different threads (such as WebWorker threads) to achieve parallel execution; For instructions with dependencies, serial coordinated execution is achieved through a pipeline buffer.

[0057] Regarding the construction of the atomic parallel instruction engine provided in the embodiments of this application: In this embodiment, the Wasm module is designed as an atomic parallel instruction engine, which can decompose and execute the received batch instruction stream in parallel. Although the above-mentioned binary communication protocol solves the communication frequency and data conversion problems by submitting batch instructions (such as instruction set 1...instruction set N) in a single communication, the Wasm module still needs to execute these instructions serially.

[0058] The atomic parallel instruction engine internally employs a multi-threaded processing mechanism and pipelining technology, such as... Figure 6 As shown, assuming the instruction set includes instruction set 1, instruction set 2, ..., instruction set N, then the instruction set atomization process includes: S601, Receive instruction set; S602, decoupling various instruction sets; Different instruction sets correspond to different contiguous memory addresses. By adhering to the length and number of instruction sets specified in the protocol, different instruction sets can be decoupled.

[0059] S603, parse the instructions in each instruction set; S604, resolving dependencies between instructions; S605, decouples dependent instruction chains within the same instruction set.

[0060] The instruction format defined by the protocol has a dependency marker in the header, which indicates the nth instruction in the instruction set that this instruction depends on. During parsing, the Wasm engine also considers the context. For example, if a function calls other instruction functions, then there is a dependency relationship. Instructions in the same instruction set that do not have dependencies are separated and decoupled.

[0061] In other words, this application embodiment dynamically decomposes the batch instruction stream into independent subtasks (such as instruction set 1 for encryption and instruction set 2 for image processing), and distributes these independent subtasks to multiple WebWorker threads (i.e., Web worker threads, which are multi-threading mechanisms provided by browsers that allow scripts to be executed in background threads, avoiding blocking the main thread (i.e., the JS main thread)). For example... Figure 6 The diagram shows Workers for instruction set 1, instruction set 2, and so on, up to instruction set N. For instructions with dependencies in context parsing or instruction header analysis (such as "encryption → signature"), the Wasm engine uses a pipeline buffer (which can be a temporary storage area outside the result area or the result area itself) to achieve serial, coordinated execution of multiple instructions. Figure 6 The instruction set 2 shown in the diagram uses a shared memory result area for Worker1 and Worker2. Encryption instructions are written to address 0x2000 in the result area, and signing instructions directly read data from address 0x2000 without waiting for all encryption to complete. The decoupled instruction chains described above can be executed in parallel within their respective processes. Generally, instructions with dependencies need to run in parallel within the same process. However, in pipelined scenarios, they don't necessarily need to be completely serial. For example, encryption and signing are serial, with the signature depending on the encryption result. But if encryption and signing are done in batches, then the encryption result of each batch can be verified. This type of pipeline also relies on shared memory.

[0062] In some implementations, the Wasm engine is also used for: If the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction will be loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading.

[0063] In some implementations, the Wasm engine is also used for: During the container (e.g., WebView) initialization phase, the pre-instantiation of the preset core Wasm module is completed, which includes the first screen local instance module.

[0064] Regarding the dynamic scalability module management system provided in the embodiments of this application: If the Wasm module loading and execution process is as follows Figure 7As shown, the Wasm module uses a synchronous full-load loading mode, meaning the main thread must first download the complete Wasm file before triggering page rendering. Memory allocation and module instantiation only begin when execution conditions are met (such as user interaction). However, this mode significantly extends the initial screen load time, and resource-intensive operations during the instantiation phase (such as memory allocation and compilation) can block the main thread, causing page stuttering. Furthermore, the Wasm module cannot be dynamically incrementally loaded; updates require a page refresh for re-initialization.

[0065] Therefore, this application embodiment constructs a dynamic modular management system based on the Wasm atomicity engine. The dynamic Wasm module loading and execution process of this application embodiment is as follows: Figure 8 As shown, it includes: S801, WebView initialization: The WebView initialization phase involves the pre-instantiation of the core Wasm module, ensuring that basic functionality is immediately available. WebView initialization specifically includes: After WebView starts, it checks if a local instance of the first screen exists. If it does, it executes the local Wasm instance; otherwise, it imports online resources for the first screen, instantiates Wasm, and then executes the local Wasm instance.

[0066] S802, Page Rendering: The page rendering process uses an on-demand loading strategy, eliminating the need to preload all resources.

[0067] S803, Code Execution: After the page rendering is complete, if code needs to be executed, it is determined whether the execution dependency instance of the instruction chain exists locally; If so, load the local instance: instruction chain Worker1...WorkerN; Otherwise, import the Wasm file online, instantiate it locally, and obtain the local instruction chain WorkerX, WorkerY...WorkerZ.

[0068] In other words, this application implements a preloading and pre-instantiation strategy for frequently used static modules (such as basic algorithm libraries). Before WebView starts, the cache is checked; if the cache is missing, the Wasm file is downloaded in advance, and instantiation preparation work such as compilation and memory allocation is completed. For dynamic algorithm modules, on-demand loading is triggered when a WebWorker is invoked. The Wasm engine implements streaming compilation and instantiation through the instantiateStreaming method, achieving dynamic runtime expansion. The WebWorker, in this application embodiment, is a Web worker thread used by the engine layer to implement parallel execution, distributing instructions to different threads for parallel processing. The instantiateStreaming method is a static method that directly compiles and instantiates the WebAssembly module from the underlying streaming source. This is the most efficient and optimized way to load Wasm code.

[0069] In summary, the process of this application embodiment can be divided into three stages: Phase 1: JS and Wasm communicate based on a binary protocol; Phase Two: The Wasm engine parses and executes instructions; Phase 3: Dynamic loading and expansion of the Wasm module.

[0070] The following examples illustrate each of the aforementioned stages.

[0071] The communication between JS and Wasm based on a binary protocol includes three aspects: memory-mapped communication, batch instruction encoding, and data type metadata. Among them: Regarding memory-mapped communication: like Figure 9 The shared memory space layout shown uses shared memory as the sole data exchange medium (WebAssembly.Memory). The standardized memory region designed in this embodiment divides the shared memory into a metadata area, an instruction area, a data area, and a result area. Wherein: The metadata area is used to store: the starting address (4B) and length (4B) of the instruction area; the starting address (4B) and length (4B) of the data area; and the starting address (4B) and length (4B) of the result area. In some embodiments, a check bit (4B, used to check memory integrity) and a reserved bit (4B, used for future expansion) are also provided. The instruction area is of fixed size and is used to store the set of instructions to be executed; The data area is dynamically allocated as a buffer area for storing complex data (such as objects and arrays) required by instructions; The results area is used to store the execution results returned by Wasm.

[0072] Regarding batch instruction encoding: The instruction set format and single instruction format provided in the embodiments of this application are respectively as follows: Figure 10 , Figure 11 As shown, the instruction set format includes: instruction set ID, number of instructions, total length, and instructions 1 to N. The single instruction format includes: dependency flags (used to indicate dependencies between instructions), opcode, parameter length, and parameter data. Both the instruction set format and the single instruction format support packaging multiple instructions. Figure 11 The opcode in the single instruction shown is used to identify the instruction type (e.g., 0x01 = addition, 0x02 = string concatenation), and the type code is defined in the range of 0x00~0x7F (lower 128 bits); the parameter length indicates the number of bytes of subsequent parameter data; the parameter data is the parameter value (e.g., numerical value, memory pointer) defined according to the opcode.

[0073] The opcodes are shown in Table 2 below, for example:

[0074] Table 2

[0075] The contents of Table 2 above can be pre-stored in the Wasm engine. When an instruction needs to be executed, the engine will perform the corresponding operation according to the mapping relationship between the opcode (instruction code), operation name (i.e. algorithm name) and parameter structure shown in Table 2, based on the instruction (from the instruction area) and data (from the data area) obtained from the shared memory, and write the operation result to the result area of ​​the shared memory.

[0076] Regarding data type metadata: This application uses TLV (Type-Length-Value) encoding to store complex data and predefines basic data types (including integers, floating-point numbers, strings, and arrays), with type codes ranging from 0x80 to 0xFF (high 128 bits). These data support nested structures (objects, multidimensional arrays). TLV is a binary data encoding format composed of three parts: "Type," "Length," and "Value," used for the serialization and parsing of structured data. TLV is the core encoding method of the protocol layer, supporting the efficient transmission of complex types (objects, arrays).

[0077]

[0078] Table 3

[0079] The data type codes in the binary protocol provided in this application are shown in Table 3 above. The basic numeric types are int32 / f32 / int64 / f64, fully covering JS's Number (double-precision floating-point number) and Wasm's core numeric types, supporting precise transmission of integers and floating-point numbers. Strings use UTF-8 encoding, compatible with Wasm's memory model (linear memory), requiring no additional conversion. Arrays adopt a "number of elements + consecutive elements" structure, suitable for handling homogeneous data (e.g., [1,2,3]). Objects adopt a "number of fields + field name + field value" structure, supporting dynamic key-value pairs (e.g., {name:"Alice",age:30}). Nested structures (e.g., [{x:1},{x:2}]) are implemented through recursive parsing, resulting in a highly self-descriptive protocol. The binary format of object data is shown in the table above. Figure 12 As shown. Here's an example: Suppose you need to perform the following operations (batch commands) in Wasm: Perform two additions: 3 + 5 and 10 + 20; Concatenate the strings: "Hello, " + "Wasm"; Create a user object: {name: "Alice", age: 30, scores: [90, 85]}; The function calcTotal (index 0x02) is called to calculate the total score: 90 + 85; I. Memory Region Partitioning Assuming the initial size of shared memory (WebAssembly.Memory) is 1 page (64KB), it is partitioned as follows: The purpose of the size of the area address range; The instruction area 0x0000 - 0x0FFF (4KB) stores the bulk instruction set; The data area 0x1000 - 0x7FFF (28KB) stores complex data such as strings and arrays. The result area (0x8000 - 0xFFFF, 32KB) stores the execution results returned by Wasm. II. Batch instruction encoding (based on instruction table): The four operations are encoded into a binary instruction stream and stored sequentially in the instruction area (starting from 0x0000): 1. First instruction: Addition (3 + 5, opcode 0x02); Operation code: 0x02 (Add); Parameter length: 0x08 (8 bytes, 2 int32 parameters); Parameter data: 0x03(3) + 0x05(5); Binary: 02 00 00 00 08 03 00 00 00 05 00 00 00; (Note: Little-endian, the most significant byte of a 4-byte integer is placed last).

[0080] 2. Second instruction: Addition (10 + 20, opcode 0x02); Operation code: 0x02; Parameter length: 0x08; Parameter data: 0x0A (10) + 0x14 (20); Binary: 02 00 00 00 08 0A 00 00 00 14 00 00 00; 3. Third instruction: string concatenation (opcode 0x01); Opcode: 0x01 (Concat); Parameter length: 0x11 (17 bytes); String 1: "Hello," (6 bytes long), i.e., 06 00 00 00 48 65 6C 6C 6F 2C 20; String 2: "Wasm" (4 bytes long), i.e., 04 00 00 00 57 61 73 6D; Binary: 01 00 00 00 11 06 00 00 00 48 65 6C 6C 6F 2C 20 04 00 00 00 5761 73 6D; 4. Fourth instruction: Create a user object (nested structure, requires data type metadata); First, store the object's original data in the data area, then reference it using instructions: Data area address 0x1000: string "Alice" (type 0x84), i.e. 84 05 00 00 00 41 6C 6963 65; Data area address 0x100A: Integer 30 (type 0x80), i.e. 80 1E 00 00 00; Data area address 0x100F: array [90,85] (type 0x85), i.e. 85 02 00 00 00 80 5A 0000 00 80 55 00 00 00; The instruction references the data area via a memory pointer: Opcode 0x0E (Set Object) + Parameter length 0x1E + Number of fields 3 + Field data (key + value pointer); Binary: 0E 00 00 00 1E 03 00 00 00 04 6E 61 6D 65 00 00 10 00 00 00 0361 67 65 00 00 10 0A 00 00 06 73 63 6F 72 65 73 00 00 10 0F 00 00; 5. Fifth instruction: Call the function calcTotal (opcode 0x10); Opcode: 0x10 (Call); Parameter length: 0x07; Function index: 0x02; Number of parameters: 1 (array pointer); Parameter data: Array address 0x100F, i.e. 10 00 00 00 07 02 00 00 00 01 0F 10 0000; III. Data type metadata encoding; Using scores [90, 85] in a user object as an example, the TLV encoding is shown: Array type code: 0x85 (array); Number of elements: 0x02 (2 elements); Element 1: 90 (type 0x80 = int32), i.e. 80 5A 00 00 00; Element 2: 85 (type 0x80 = int32), i.e. 80 55 00 00 00; Full code: 85 02 00 00 00 80 5A 00 00 00 80 55 00 00 00; (Note: Little-endian, 4-byte length with the most significant byte at the end).

[0081] IV. Wasm Execution Flow; Read instruction: Wasm parses the binary instruction stream starting from instruction area 0x0000 and processes it sequentially according to the opcode.

[0082] Perform addition: Parse instruction 0x02, extract parameters 3 and 5, calculate 8, and store the result in result area 0x8000.

[0083] The second instruction, 0x02, is parsed to calculate 10 + 20 = 30, and the result is stored in 0x8004.

[0084] String concatenation: Parse instruction 0x01, read "Hello," and "Wasm", concatenate them into "Hello, Wasm", store the result in data area 0x2000, and record the address in result area 0x8008.

[0085] Creating an object: Parse the 0x0E instruction, read "Alice", 30, and [90,85] from the data area, assemble them into an object structure, store it in the data area 0x3000, and record the address in the result area 0x800C.

[0086] Calling the function: Parse instruction 0x10, call the calcTotal function at index 0x02, pass in array address 0x100F, calculate 90+85=175, and store the result in 0x8010.

[0087] The multi-task interaction process between JS and Wasm based on shared memory, for example Figure 13 As shown, it includes: S131, JS writes the instruction set to the instruction area of ​​shared memory; S132, The JS instruction to write data to the shared memory data area requires data; S133, JS writes instructions and data addresses to the shared memory metadata area; S134. JS executes Wasm to instantiate objects through function calls; S135. The Wasm instantiated object reads the address from the metadata area of ​​the shared memory, and the Wasm instantiated object reads instruction data from the instruction area and data area of ​​the shared memory, thereby performing multitasking. S136. The Wasm instantiated object writes the result (i.e., the result of multi-task processing) to the result area of ​​shared memory, and the Wasm instantiated object writes the result address to the metadata area of ​​shared memory. S137. Wasm instantiates an object and completes multi-task processing, then notifies JS. S138, JS reads the result address from the metadata area of ​​shared memory, and JS reads the result from the result area of ​​shared memory.

[0088] Regarding Wasm engine command parsing and execution: The Wasm engine's atomic parsing instruction set process is as follows: Figure 14 As shown, it includes: Read binary instruction sets from the shared memory "instruction area", for example, instruction set a...instruction set n; Parse the instruction set header to obtain the total number of instructions; Each instruction is parsed, and based on its opcode, it is routed to the corresponding processing logic (the Wasm module contains the execution algorithms for each instruction). Based on the processing logic corresponding to each instruction, locate the target module instance. If the target module instance does not exist locally, dynamically request it from the server.

[0089] After the module is loaded, the parameter area of ​​the instruction (including parameter length and parameter data) is decoded by TLV. The Type, Length and Value are read by pointer offset and directly mapped to data structures accessible by Wasm. For example, the TLV stream of nested objects is parsed into a sequence of bytes in contiguous memory.

[0090] The Wasm engine constructs a Directed Acyclic Graph (DAG) based on the dependency tag field of the instructions in the instruction set, and identifies parallel modules with no dependencies and serial modules with dependencies, such as encryption instructions and signing instructions having a serial dependency.

[0091] For instructions that have no dependencies (such as batch user data encryption), they are distributed to different WebWorkers for parallel execution, and intermediate results are passed through shared memory.

[0092] For instructions with dependencies, serial coordination is achieved through a "pipeline buffer." After the preceding module (such as the encryption module) completes its execution, it writes the result to the result area of ​​shared memory and updates the status flag. Subsequent modules (such as the signature module) listen to the status flag through atomic operations. Once "data ready" is detected, they directly read data from the buffer and execute it without additional function calls. Here, a Directed Acyclic Graph (DAG) is a graph structure composed of vertices and directed edges, with no loop paths, and is commonly used to represent task dependencies. In this embodiment, the DAG is the model used by the engine layer to parse instruction dependencies and to identify parallel and serial tasks.

[0093] For example Figure 14 As shown, in instruction set a, instructions 1, 3, ..., x have dependencies and are assigned to the same thread, Worker1, for execution; instructions 2, 4, ..., y have dependencies and are assigned to the same thread, Worker2, for execution; and instructions 5, 6, ..., z have dependencies and are assigned to the same thread, Worker3, for execution. Instructions with dependencies form an instruction chain. Similarly, instructions in instruction chain n are assigned to the same thread, WorkerN, for execution. The instruction set follows the same logic and will not be elaborated further.

[0094] Suppose the Wasm engine receives an instruction set containing three instructions, such as an encryption instruction, a signature instruction, and a verification instruction. The "signature module" corresponding to the signature instruction is not cached locally and needs to be dynamically loaded. Then, the corresponding Wasm engine's parsing, encryption, signature, and verification process would be as follows: Figure 15 As shown, it includes: S151. Fetch the instruction set from the shared memory instruction area; S152, Parse the instruction set header; The instruction set includes three instructions: Command 1: Encrypt (Opcode 1); Instruction 2: Signature (Opcode 2); Command 3: Verify (Opcode 3).

[0095] S153, Parse instructions one by one; S154a, Regarding instruction 1: Parameters for decoding encrypted instructions (offline memory byte stream); S154b, for instruction 2: Since the local signature module is missing, the signature module is dynamically loaded. The parameters of the decoded signature instruction are obtained through a memory pointer.

[0096] S154c, for instruction 3: The parameters of the decoding signature instruction are used to obtain the signature result through a memory pointer.

[0097] S155, Construct the dependency graph; That is, based on the dependency tags of encryption instructions, signing instructions, and verification instructions, it is determined that there are dependencies between encryption instructions, signing instructions, and verification instructions, and they are assigned to the same thread for processing.

[0098] S156. By allocating the same thread for encryption instructions, signature instructions, and verification instructions, schedule the encryption module, signature module, and verification module to execute the encryption instructions, signature instructions, and verification instructions respectively; S157. Store the execution result of the verification instruction into the shared memory result area (of course, the results of the encryption instruction, signature instruction, and verification instruction will all be placed in the result area).

[0099] In other words, in this embodiment, the Wasm engine reads the instruction set header through atomic operations (Atomics.load) to confirm the total number of instructions (3 in the above embodiment). After parsing, it routes the instruction to the corresponding processing module according to the instruction opcode of each instruction (for example, encryption instructions are sent to the encryption module, signature instructions are sent to the signature module, and verification instructions are sent to the verification module). When the target processing module is not found locally, the engine pauses the execution of the current instruction and triggers the dynamic loading process. After the target processing module is downloaded and instantiated, the Wasm engine performs TLV decoding on the parameter area of ​​each instruction, converting complex data into a continuous byte stream in Wasm linear memory. The decoded data is directly mapped to Wasm linear memory, avoiding the secondary conversion from JSON serialized strings to binary, allowing Wasm modules to be directly accessed through memory pointers. Finally, the execution order is ensured by scheduling instructions through the dependency graph.

[0100] Regarding dynamic loading and expansion of modules: The end-to-end optimization of resource module loading provided in this application embodiment, such as... Figure 16 As shown, the process includes "cache hit → direct reuse" → "cache miss → preloading to fill" → "first call → instantiation binding". This reduces network requests through caching and fills cache gaps through preloading.

[0101] Dynamic extensibility module loading, for example Figure 16 As shown, proceed in the following priority order: Priority 1: When a module is needed during webview initialization or Wasm atomic thread, first check the memory cache (for instantiated modules, the fastest, in microseconds). Priority 2: If a cache miss occurs, check the local cache (the compiled WebAssembly.Module to avoid duplicate compilation, millisecond-level cache). Priority 3: If still not found, check the HTTP cache (Wasm binary file, to avoid duplicate downloads, in milliseconds); that is, the browser's cache, which is divided into memory cache and disk cache, can be controlled through HTTP response headers.

[0102] Priority 4: If none of the above are found, a network request is triggered, and the downloaded file is stored in the cache at each level. In other words, the Wasm module file is pulled from the server for future use.

[0103] In some embodiments, when a cache miss occurs, modules that may be used in the future are downloaded in advance and preloaded.

[0104] In some embodiments, when the page is initialized, "essential modules for the first screen" (such as the encryption module in the login scenario) are preloaded to ensure that core functions are not delayed. In some embodiments, requestIdleCallback is used to preload low-priority but potentially useful modules, such as advanced editing features, when the browser is idle.

[0105] In some embodiments, pre-instantiation shifts the latency from runtime to the initialization phase. The engine converts the .Wasm binary code into target platform machine code (such as x86 / ARM instructions) via a compilation thread, avoiding the JIT compilation latency of the first runtime call. For example, the time-consuming steps of "compilation" and "instantiation" are moved from "when the user triggers the business logic" to "application initialization phase" (such as after the page has loaded and resources are idle).

[0106] In summary, this application's embodiment divides shared memory into three areas: an instruction area, a data area, and a result area. All instructions and data are packaged in a unified binary format and transmitted to Wasm in one go. For example, where 10 encryption instructions previously required 10 calls, now they are packaged into a single instruction stream and transmitted all at once, reducing the number of communications from 10 to 1. Moreover, data is not copied back and forth; it is read and written directly in shared memory, virtually eliminating the overhead of format conversion (the initial conversion between the original data and the "conventional binary format").

[0107] Furthermore, this embodiment employs a multi-threaded processing mechanism and pipeline technology within the Wasm engine. After receiving a batch of instructions, Wasm can break them down into smaller tasks based on contextual relationships such as input / output parameters or dependency flags in the instruction header, and distribute them to multiple threads for parallel processing. Simultaneously, a pipeline is established for dependent tasks such as "encryption → signing," allowing signing to proceed as soon as a portion of the result is calculated, without waiting for encryption to be fully completed, thus achieving higher efficiency.

[0108] Furthermore, in this embodiment of the application, to address the issue of slow loading, the core modules are cached locally in the application in advance. If the cache does not exist, the webview implements "preloading and pre-instantiation" at startup, so that the modules can be used as soon as the page is opened. Non-core modules are dynamically loaded when needed by the webworker in the Wasm engine, and are processed in a background thread without blocking the main thread.

[0109] Therefore, the embodiments of this application can achieve the following beneficial effects: Improved communication efficiency: Because of batch command transmission and zero copying, the overhead of communication and format conversion is reduced by an order of magnitude; Improved execution speed: The parallel engine fully utilizes multi-core CPUs, cutting the processing time of complex tasks in half and eliminating waiting time for dependent tasks; Improved user experience: Preloading + background instantiation significantly speeds up the first screen loading, and the page will no longer freeze due to loading Wasm.

[0110] The following describes the device or apparatus provided in the embodiments of this application, and the explanations or examples of the same or corresponding technical features as those described in the above methods will not be repeated hereafter.

[0111] An electronic device is provided in an embodiment of this application, see [link to example]. Figure 17 For example, including: Processor 600 is used to read the program from memory 620 and execute the following procedures: The JS engine writes at least one instruction set to the instruction area of ​​a preset shared memory and writes the data required for the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; the instruction is a binary instruction. The Wasm engine retrieves instruction sets from the instruction area of ​​the shared memory, parses each instruction set according to a preset instruction set format, and parses each instruction in each instruction set according to a preset instruction format to obtain each instruction. For each instruction, the required data is retrieved from the data area of ​​the shared memory, and based on the required data and the preset mapping relationship between instructions and algorithms, the corresponding algorithm is called to execute the instruction, and the execution result is stored in the result area of ​​the shared memory.

[0112] In some embodiments, the processor 600 is further configured to read a program from the memory 620 and execute the following processes: The Wasm engine notifies the JS engine that the instruction execution is complete. The JS engine reads the instruction execution results from the result area of ​​the shared memory.

[0113] In some implementations, when executing each instruction via the Wasm engine: For instructions that have no dependencies, they are assigned to different threads to achieve parallel execution; For instructions with dependencies, serial coordinated execution is achieved through a pipeline buffer.

[0114] In some implementations, the Wasm engine identifies instructions with no dependencies and instructions with dependencies by constructing a directed acyclic graph (DAG) based on the dependency tag field of instructions in the instruction set.

[0115] In some implementations, the data stored in the data area is TLV-encoded data.

[0116] In some embodiments, the processor 600 is further configured to read a program from the memory 620 and execute the following processes: If it is determined that the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction is loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading.

[0117] In some embodiments, the processor 600 is further configured to read a program from the memory 620 and execute the following processes: During the container initialization phase, the pre-instantiation of the preset core Wasm module is completed. The core Wasm module includes the first screen local instance module.

[0118] In some embodiments, the processor 600 is further configured to read a program from the memory 620 and execute the following processes: Before the container starts, for static modules whose usage frequency is greater than a preset value, it is checked whether there is a local instance. If not, the Wasm file is loaded online and instantiated locally. The static module includes a basic algorithm library.

[0119] Transceiver 610 is used to receive and send data under the control of processor 600.

[0120] Among them, Figure 17 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 600 and memory represented by memory 620 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 can be multiple components, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium, including wireless channels, wired channels, optical fibers, etc. For different user equipment, the user interface 630 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0121] The processor 600 is responsible for managing the bus architecture and general processing, while the memory 620 can store the data used by the processor 600 when performing operations.

[0122] In some implementations, the processor 600 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a CPLD (Complex Programmable Logic Device), and the processor may also employ a multi-core architecture.

[0123] The processor executes any of the methods described in the embodiments of this application according to the obtained executable instructions by calling a computer program stored in memory. The processor and memory may also be physically separated.

[0124] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0125] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0126] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0127] Any of the devices or apparatuses provided in the embodiments of this application can specifically be desktop computers, portable computers, smartphones, tablet computers, personal digital assistants (PDAs), etc. They may include a central processing unit (CPU), memory, input / output devices, etc. Input devices may include keyboards, mice, touchscreens, etc., and output devices may include display devices such as liquid crystal displays (LCDs) and cathode ray tubes (CRTs).

[0128] The memory may include read-only memory (ROM) and random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In the embodiments of this application, the memory may be used to store the program of any of the methods provided in the embodiments of this application.

[0129] The processor executes any of the methods described in the embodiments of this application according to the program instructions stored in the memory.

[0130] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the methods described in the above embodiments. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0131] This application provides a computer-readable storage medium for storing computer program instructions used in the apparatus provided in the above-described embodiments, including a program for performing any of the methods provided in the above-described embodiments. The computer-readable storage medium may be a non-transitory computer-readable medium.

[0132] The computer-readable storage medium can be any available medium or data storage device that a computer can access, including but not limited to magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MOs), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)).

[0133] It should be understood that: The access technology used by entities in a communication network to transmit traffic can be any suitable current or future technology, such as WLAN (Wireless Local Access Network), WiMAX (WiMAX), LTE, etc. A. 5G, Bluetooth, infrared, etc.; in addition, the embodiments may also apply wired technologies, such as IP-based access technologies, such as wired networks or fixed lines.

[0134] An embodiment suitable for implementation as software code or as part thereof and for operation using a processor or processing capabilities is independent of the software code and can be specified using any known or future-developed programming language, such as high-level programming languages, such as Objective-C. C, C++, C#, Java, Python, Javascript, other scripting languages, or low-level programming languages ​​such as machine language or assemblers.

[0135] The implementation of the embodiments is hardware-independent and can be implemented using any known or future-developed hardware technology or any combination thereof, such as microprocessors or CPUs (Central Processing Units), MOS (Metal-Oxide-Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter-Coupled Logic), and / or TTL (Transistor-Transistor-Transistor). Transistor logic).

[0136] The embodiments may be implemented as individual devices, apparatuses, units, components or functions, or in a distributed manner. For example, one or more processors or processing functions may be used or shared in the process, or one or more processing segments or processing portions may be used and shared in the process, wherein one or more physical processors may be used to implement one or more processing portions dedicated to a particular process as described.

[0137] The device can be implemented by a semiconductor chip, a chipset, or a (hardware) module that includes such a chip or chipset.

[0138] The implementation can also be implemented as any combination of hardware and software, such as ASIC (Application-Specific IC (Integrated Circuit)) components, FPGA (Field Programmable Gate Array) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

[0139] The embodiments can also be implemented as computer program products, including a computer-usable medium in which computer-readable program code is embodied, the computer-usable program code being adapted to perform the processes described in the embodiments, wherein the computer-usable medium may be a non-transitory medium.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0144] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An instruction execution system, characterized in that, The system includes: a JS engine, shared memory, and a Wasm engine; among which... The JS engine is configured to: write at least one instruction set to the instruction area of ​​the shared memory; write the data required by the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; and the instruction is a binary instruction. The shared memory includes an instruction area, a data area, and a result area; wherein, the instruction area is used to store the set of instructions to be executed; the data area is used to store the data required by the instructions; and the result area is used to store the execution results returned by the Wasm engine. The Wasm engine is used to obtain instruction sets from the instruction area of ​​the shared memory, parse each instruction set according to a preset instruction set format, and parse each instruction in each instruction set according to a preset instruction format to obtain each instruction; for each instruction, it obtains the data required by the instruction from the data area of ​​the shared memory, and based on the data required by the instruction and according to the preset mapping relationship between instructions and algorithms, it calls the algorithm corresponding to the instruction, executes the instruction, and stores the execution result in the result area of ​​the shared memory; The Wasm engine is also used for: If the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction will be loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading; The Wasm engine is also used for: During the container initialization phase, the pre-instantiation of the preset core Wasm module is completed. The core Wasm module includes the first screen local instance module. The JS engine is also used for: Before the container starts, for static modules whose usage frequency is greater than a preset value, it is checked whether there is a local instance. If not, the Wasm file is loaded online and instantiated locally. The static module includes a basic algorithm library.

2. The system according to claim 1, characterized in that, The instruction format includes dependency tags used to indicate dependencies between instructions; The Wasm engine, when executing each instruction: For instructions that have no dependencies, they are assigned to different WebWorker threads to achieve parallel execution; For instructions with dependencies, a pipeline buffer is used to achieve serial coordinated execution.

3. The system according to claim 2, characterized in that, The Wasm engine identifies instructions with no dependencies and instructions with dependencies by constructing a directed acyclic graph (DAG) based on the dependency tag field of the instructions in the instruction set.

4. The system according to claim 1, characterized in that, The data stored in the data area is TLV-encoded data.

5. The system according to claim 1, characterized in that, The instruction set format is as follows: Instruction set ID, number of instructions, total length of instruction set, and individual instructions.

6. The system according to claim 1, characterized in that, The instruction format is as follows: Dependency flags, opcodes, instruction parameter length, and parameter data; The dependency tag is used to indicate the dependency relationship between instructions.

7. The system according to claim 1, characterized in that, The shared memory also includes a metadata area, which is used to store the starting address and length of the instruction area, data area and result area; The JS engine is also used to write instruction addresses and data addresses to the metadata area of ​​the shared memory; The Wasm engine is also used to read instruction addresses and data addresses from the metadata area.

8. A method for executing instructions, characterized in that, Applied to the system according to any one of claims 1 to 7, the method comprises: The JS engine writes at least one instruction set to the instruction area of ​​a preset shared memory and writes the data required for the instruction to the data area of ​​the shared memory; wherein each instruction set includes at least one instruction; the instruction is a binary instruction. The Wasm engine retrieves instruction sets from the instruction area of ​​the shared memory, parses each instruction set according to a preset instruction set format, and parses each instruction in each instruction set according to a preset instruction format to obtain each instruction. For each instruction, the required data is retrieved from the data area of ​​the shared memory, and based on the required data and the preset mapping relationship between instructions and algorithms, the corresponding algorithm is called to execute the instruction, and the execution result is stored in the result area of ​​the shared memory.

9. The method according to claim 8, characterized in that, The method further includes: The Wasm engine notifies the JS engine that the instruction execution is complete. The JS engine reads the instruction execution results from the result area of ​​the shared memory.

10. The method according to claim 8, characterized in that, When executing each instruction through the Wasm engine: For instructions that have no dependencies, they are assigned to different threads to achieve parallel execution; For instructions with dependencies, serial coordinated execution is achieved through a pipeline buffer.

11. The method according to claim 8, characterized in that, The method further includes: If it is determined that the algorithm corresponding to the instruction does not exist locally, the algorithm corresponding to the instruction is loaded in the following priority order: Memory caching, local caching, HTTP caching, online loading.

12. The method according to claim 8, characterized in that, The method further includes: During the container initialization phase, the pre-instantiation of the preset core Wasm module is completed. The core Wasm module includes the first screen local instance module.

13. The method according to claim 8, characterized in that, The method further includes: Before the container starts, for static modules whose usage frequency is greater than a preset value, it is checked whether there is a local instance. If not, the Wasm file is loaded online and instantiated locally. The static module includes a basic algorithm library.

14. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method according to any one of claims 8 to 13 in accordance with the obtained program.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing the computer to perform the method according to any one of claims 8 to 13.

Images