System and methods for embedding WASM interpreter within WASI-compliant javascript runtime

Abstract

A computer-implemented method for extending a first JavaScript runtime is disclosed. A WebAssembly (Wasm) interpreter is embedded within the first JavaScript runtime based on integrating, in the first JavaScript runtime a runtime component and a Wasm interpreter manager. The runtime component implements, at least, a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript and a WebAssembly System Interface (WASI) -compliant Wasm runtime. The Wasm interpreter manager is configured to track compiled Wasm modules and instantiated Wasm modules.

Description

SYSTEM AND METHODS FOR EMBEDDING WASM INTERPRETER WITHIN WASI-COMPLIANT JAVASCRIPT RUNTIMETECHNICAL FIELD

[0001] The present application relates to software interfaces and, more particularly, to a system and methods for extending JavaScript runtimes to support WebAssembly modules.BACKGROUND

[0002] WebAssembly (Wasm) is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications. Wasm describes a memory-safe, sandboxed execution environment. Initializing a Wasm sandbox has a considerably lower cold start time than other sandboxing technologies, and is regarded as an effective technology for running serverless applications.

[0003] BRIEF SUMMARY

[0004] In accordance with one aspect, the present disclosure describes a computer-implemented method for extending a first JavaScript runtime. The method may include: embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime: a runtime component that implements: a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; and a WebAssembly System Interface (WASI) -compliant Wasm runtime, and a Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.

[0005] In some implementations, the first JavaScript runtime may comprise a WASI-compliant JavaScript interpreter.

[0006] In some implementations, the first JavaScript runtime may comprise the QuickJS JavaScript engine.

[0007] In some implementations, embedding the Wasm interpreter within the first JavaScript runtime may include integrating, in the first JavaScript runtime, an application programming interface (API) layer that implements a plurality of elements defined in a standard web API for Wasm JavaScript interface.

[0008] In some implementations, the plurality of elements of the standard web API for Wasm JavaScript interface may include at least: a Memory object comprising a resizable memory buffer that defines Wasm memory spaces; a Global object representing a global variable instance that is accessible from JavaScript and Wasm; a Function object containing JavaScript functions that can be imported to Wasm or exported from it; a Table object comprising an array-like structure representing a Wasm table that stores homogeneous references; a Module object comprising a compiled Wasm binary within JavaScript code; and an Instance object containing exported Wasm functions.

[0009] In some implementations, the memory allocator may be configured to handle memory growth for growing a number of pages within the memory space.

[0010] In some implementations, implementing the memory allocator may include creating a JavaScript binding for a first memory space associated with a Wasm module that is loaded into a second memory space associated with the first JavaScript runtime.

[0011] In some implementations, implementing the memory allocator may include shallow copying the first memory space associated with the Wasm module.

[0012] In some implementations, the runtime component may further implement a function binder configured to create JavaScript bindings for exported functions that are defined within a Wasm module.

[0013] In some implementations, the function binder may be configured to: detect a direct function invocation of an exported function; and in response to detecting the direct function invocation, serializing a function name and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.

[0014] In some implementations, the function binder may be configured to: detect an indirect function invocation of an exported function; and in response to detecting the indirect function invocation, serializing a function pointer, table name, and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.

[0015] In some implementations, the runtime component may further implement a context manager configured to provide references to states of Wasm instances.

[0016] In some implementations, the runtime component may further implement an event loop scheduler configured to manage execution of one or more methods defined in a standard web API for Wasm JavaScript interface.

[0017] In some implementations, the runtime component may further implement a type converter configured to convert JavaScript types to Wasm types and to convert Wasm results to JavaScript types.

[0018] In another aspect, the present disclosure describes a computing system. The computing system includes a processor and a memory coupled to the processor. The memory stores computer-executable instructions that, when executed by the processor, may configure the processor to extend a first JavaScript runtime executing on the processor, wherein extending the first JavaScript runtime includes: embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime: a runtime component that implements: a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; and a WebAssembly System Interface (WASI) -compliant Wasm runtime, and a Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.

[0019] In yet another aspect, a non-transitory computer-readable medium is disclosed. The computer-readable medium stores instructions that, when executed by a processor, may configure the processor to extend a first JavaScript runtime executing on the processor, wherein extending the first JavaScript runtime includes: embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime: a runtime component that implements: a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; and a WebAssembly System Interface (WASI) -compliant Wasm runtime, and a Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.

[0020] Other aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures. Example embodiments of the present application are not limited to any particular operating system, system architecture, mobile device architecture, server architecture, or computer programming language.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Embodiments are described in detail below, with reference to the following drawings:

[0022] FIG. 1 illustrates an exemplary design of an extended JavaScript runtime of the present disclosure;

[0023] FIG. 2A is high-level schematic diagram of an example computing device;

[0024] FIG. 2B shows a simplified organization of software components stored in a memory of the example computing device of FIG. 2A;

[0025] FIG. 3 is a schematic diagram illustrating an exemplary design of a memory allocator implementation within the extended JavaScript runtime of the present disclosure;

[0026] FIG. 4 is a schematic diagram illustrating an exemplary design of a function binder implementation within the extended JavaScript runtime of the present disclosure;

[0027] FIG. 5 shows an example OpenCV. js program capable of running in Wasm within the extended JavaScript runtime of the present disclosure; and

[0028] FIG. 6 illustrates how OpenCV. js interacts with a Wasm instance.

[0029] Like reference numerals are used in the drawings to denote like elements and features.

[0030] DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

[0031] In the present application, the term “and / or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

[0032] In the present application, the phrase “at least one of …or…” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

[0033] WebAssembly System Interface, or WASI, is a group of standards-track API specifications for software compiled to the Wasm standard. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm. A “WASI-compliant” program is one that can be compiled to a wasm32-wasi binary target. Modern JavaScript interpreters that are WASI-compliant do not include an inner Wasm interpreter, i.e., a runtime component that reads, parses, and executes Wasm bytecode directly. QuickJS, a lightweight, fast JavaScript engine that is WASI-compliant, is one such example. QuickJS includes a built-in JavaScript runtime, an interpreter, and a just-in-time (JIT) compiler. Without a Wasm interpreter, however, QuickJS does not support software with embedded Wasm modules (e.g., OpenCV. js) . For example, if user code uses a npm package that has an embedded Wasm module, during execution with standard QuickJS, a namespace exception would be raised in the runtime.

[0034] The present application discloses a system and methods for extending a JavaScript runtime to include a WASI-compliant Wasm interpreter. Specifically, the present application describes techniques for embedding a Wasm interpreter within a WASI-compliant JavaScript interpreter, which enables software (e.g., nm packages like OpenCV. js) that uses Wasm modules to be supported. The example embodiments described below focus on extensions of the standard QuickJS runtime. Various open-source, WASI-compliant versions of QuickJS are available, and a Wasm interpreter can be suitably built on top of such QuickJS versions while ensuring that WASI-compliancy is not violated. It will be understood, however, that the techniques described herein may be applicable to other WASI-compliant JavaScript runtimes.

[0035] As a general overview, the extensions of the QuickJS runtime are manifested in two key components: an API layer and a backend for including a WASI-compliant Wasm interpreter. The API layer implements all the elements in the standard WebAssembly Web API using QuickJS Rust bindings. These elements include, at least: a Memory object (resizable memory buffers that define Wasm memory spaces, made out of 64KB pages) ; a Global object (aglobal variable instance, accessible from both JavaScript and Wasm) ; a Function object (normal JavaScript functions that can be imported to Wasm or exported from it) ; a Table object (an array-like structure representing a WebAssembly table, which stores homogeneous references, like function references) ; a Module object (acompiled / pre-instantiated Wasm binary within JavaScript code) ; and an Instance object (Wasm instance that can interact with JavaScript code) .

[0036] The present application describes an approach for extending the QuickJS runtime to include a WASI-compliant Wasm interpreter. First, low-level WASM primitive data types (e.g., i32, f64, etc. ) are mapped to high-level types of JavaScript. Second, the backends associated with the mentioned elements in the API layer are implemented. For example, for the backend part of “Tables” , indirect function calls are enabled through binding JavaScript closures to each Wasm interpreter context. In this way, all modifications done through these indirect calls are kept consistent throughout the lifetime of the Wasm module. Third, a Wasm interpreter manager is implemented. The Wasm interpreter manager tracks, at least, (1) compiled Wasm modules, which enables reusing the same compiled module (s) , and (2) instantiated Wasm modules. By tracking the instantiated modules, each instance’s status after each change (e.g., a function call) can be accessed and monitored.

[0037] FIG. 2A is a high-level operation diagram of an example computing device 105. The computing device 105 can be configured to implement one or more of the disclosed techniques for extending a JavaScript runtime to include an embedded Wasm interpreter. The example computing device 105 includes a variety of modules. For example, the example computing device 105, may include a processor 200, a memory 210, an input interface module 220, an output interface module 230, and a communications module 240. As illustrated, the foregoing example modules of the example computing device 105 are in communication over a bus 250.

[0038] The processor 200 is a hardware processor. For example, the processor 200 may comprise one or more ARM, Intel x86, PowerPC processors or the like.

[0039] The memory 210 allows data to be stored and retrieved. The memory 210 may include, for example, random access memory, read-only memory, and persistent storage. Persistent storage may be, for example, flash memory, a solid-state drive or the like. Read-only memory and persistent storage are a computer-readable medium. A computer-readable medium may be organized using a file system such as may be administered by an operating system governing overall operation of the example computing device 105.

[0040] The input interface module 220 allows the example computing device 105 to receive input signals. Input signals may, for example, correspond to input received from a user. The input interface module 220 may serve to interconnect the example computing device 105 with one or more input devices. Input signals may be received from input devices by the input interface module 220. Input devices may, for example, include one or more of a touchscreen input, keyboard, trackball or the like. In some implementations, all or a portion of the input interface module 220 may be integrated with an input device. For example, the input interface module 220 may be integrated with one of the aforementioned examples of input devices.

[0041] The output interface module 230 allows the example computing device 105 to provide output signals. Some output signals may, for example allow provision of output to a user. The output interface module 230 may serve to interconnect the example computing device 105 with one or more output devices. Output signals may be sent to output devices by output interface module 230. Output devices may include, for example, a display screen such as, for example, a liquid crystal display (LCD) , a touchscreen display. Additionally, or alternatively, output devices may include devices other than screens such as, for example, a speaker, indicator lamps (such as for, example, light-emitting diodes (LEDs) ) , and printers. In some implementations, all or a portion of the output interface module 230 may be integrated with an output device. For example, the output interface module 230 may be integrated with one of the aforementioned output devices.

[0042] The communications module 240 allows the example computing device 105 to communicate with other electronic devices and / or various communications networks. For example, the communications module 240 may allow the example computing device 105 to send or receive communications signals. Communications signals may be sent or received according to one or more protocols or according to one or more standards. For example, the communications module 240 may allow the example computing device 105 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM) , Code Division Multiple Access (CDMA) , Evolution Data Optimized (EVDO) , Long-term Evolution (LTE) or the like.

[0043] Additionally, or alternatively, the communications module 240 may allow the example computing device 105 to communicate using near-field communication (NFC) , via Wi-FiTM, using BluetoothTM or via some combination of one or more networks or protocols. Contactless payments may be made using NFC. In some implementations, all or a portion of the communications module 240 may be integrated into a component of the example computing device 105. For example, the communications module may be integrated into a communications chipset.

[0044] Software comprising instructions is executed by the processor 200 from a computer-readable medium. For example, software may be loaded into random-access memory from persistent storage of memory 210. Additionally, or alternatively, instructions may be executed by the processor 200 directly from read-only memory of memory 210.

[0045] FIG. 2B depicts a simplified organization of software components stored in memory 210 of the example computing device 105. As illustrated, these software components include application software 270 and an operating system 280.

[0046] The application software 270 adapts the example computing device 105, in combination with the operating system 280, to operate as a device performing a particular function. The operating system 280 is software. The operating system 280 allows the application software 270 to access the processor 200, the memory 210, the input interface module 220, the output interface module 230 and the communications module 240. The operating system 280 may be, for example, Apple iOSTM, Google’s AndroidTM, LinuxTM, Microsoft WindowsTM, or the like.

[0047] Reference is made to FIG. 1 which illustrates an exemplary design of an extended JavaScript runtime of the present disclosure. In at least some embodiments, the API layer may be a routine implementation mirroring the standard Web API for Wasm JavaScript interface. Various open-source implementations for the API layer may be suitable. The JavaScript API layer is loaded by QuickJS runtime, allowing a user to interact with the Wasm interpreter through a standard set of elements. Actions assigned to each element are mapped to different components within the backend that are integrated into the QuickJS runtime.

[0048] The Runtime Component illustrated in FIG. 1 includes six constituent components: a Memory Allocator, a Function Binder, a Context Manager, an Event Loop I / O, a Wasm2JS Type Converter, and a WASI-compliant Wasm Runtime. Each of the components will be described in greater detail below.

[0049] Memory Allocator: Wasm memory spaces are the main elements for holding operands, operators, and data associated with each operation. Memory spaces take up the largest portion of Wasm instance states; therefore, a sound management of memory spaces is crucial. The Memory Allocator component ensures that (a) both Wasm and JavaScript have access to the same memory space, (b) changes to the memory space can be seen by both JavaScript and Wasm, and (c) a method for managing memory growth within a memory space is provided.

[0050] The design of the Memory Allocator component is described with reference to an OpenCV. js example, as shown in FIG. 3. An OpenCV Wasm binary is loaded into the QuickJS memory space. To ensure that conditions (a) and (b) are satisfied, JavaScript bindings for OpenCV Memory are created based on the starting address of the OpenCV memory space which resides inside QuickJS memory space. In some implementations, a QuickJS native call “JS_NewArrayBuffer” may be used for the bindings. Using this call, the already existing OpenCV memory space can be shallow copied. In this way, references to the same memory are obtained: (1) one held by QuickJS with which it can manipulate OpenCV memory after calling host functions, (2) one held by OpenCV Wasm binary itself with which it can manipulate memory after calling non-host functions.

[0051] For condition (c) , a suitable Wasm runtime, such as WASMI, can be selected and designated to handle memory growth. In the case that the requested number of pages exceeds the limit set for the memory space, an exception can be returned to the user, indicating failure in memory growth.

[0052] Function Binder: The functions section is the largest section within a Wasm binary. These functions fall under one of three categories: (1) imported functions (host functions) , (2) internal functions, and (3) exported functions.

[0053] In case of host functions, since the functions have already been written in JavaScript, there is no need to create JavaScript bindings. The only required task is to link them to the runtime with the runtime’s Linker and making sure that argument types match. Internal functions are the helper functions that are not exposed to the user but are used by exported functions. Since they are not exposed to the user, executing them will be handled by the Wasm runtime and there is no need for JavaScript bindings.

[0054] Unlike these first two function types, exported functions are native Wasm functions without any JavaScript bindings. As a consequence, JavaScript bindings need to be created for exported functions so that users can invoke them.

[0055] In general, there are two types of invoking exported functions in Wasm: (1) direct invoke, where the function is directly exported from Wasm and can be called; and (2) indirect invoke, where functions reside within Wasm Tables and first have to be retrieved by Table.get (func_ptr) method. Once the functions have been retrieved, they can be invoked with user arguments. Functions within tables are mutable, that is, they can change dynamically during execution based on the program flow.

[0056] At the time of invocation, the only thing that the user provides is an argument list. Therefore, in providing the runtime, it is required to ascertain what instance a function is being invoked on, and also in case of indirect calls, which table is used for pulling the function from. One way to solve this issue is to intercept the invocation and send down this metadata information alongside user arguments. This approach is inefficient as the metadata information would need to be provided every time and because it requires the tedious task of reasoning about the data flow of the program.

[0057] One possible approach proposed in the present application is to use a QuickJS native call, “JS_NewCFunctionData” . This call creates a JavaScript function to which “extra data” , in addition to user arguments, can be bound. The extra data is added in the form of a list of bytes, and so a serialization / deserialization method for the data structure used for storing this extra data is needed.

[0058] Towards this goal, as shown in Figure 4 above, a Function Binder component is implemented. The Function Binder binds function name and instance ID in case of direct call (shown in “Function export” box in FIG. 4) , and function pointer, table name, and instance ID in case of indirect call to the function (shown in “Table export” box in FIG. 4) . This information is bound to the function during instantiation, and upon invocation (which can happen at any time) it is possible to pinpoint exactly what instance and what table is being used for invocation, removing the need for sending down any information.

[0059] Context Manager: Context refers to the state of each Wasm instance that is being used with JavaScript code. Many interactions with a Wasm instance can change its state, such as function calls or memory growth. Context Manager is the component  that provides mutable (for actions like function call) or immutable (for actions like getting the value of a global) references to Wasm instances’s tates.

[0060] Event Loop IO: Some of the methods described in Wasm Web API are asynchronous methods, meaning that executing them will require yielding to the event loop scheduler. The extended QuickJS runtime of the present disclosure is equipped with an event loop that manages running these methods from Wasm Web API.

[0061] Wasm2JS Type Converter: Wasm is a low-level binary format; it only has a few primitive types (i32, i64, f32, f64) . JavaScript, on the other hand, has a rich set of types like objects, arrays, numbers, etc. Since the Wasm interpreter is called from a JavaScript program, a mapping mechanism is implemented that converts JavaScript types to Wasm types and after getting the results from Wasm, converts Wasm results to JavaScript types.

[0062] WASI-compliant Wasm Runtime: A Wasm runtime is desired that runs Wasm functions and manipulates the state of the Wasm instance in a consistent fashion until the interaction with the Wasm instance finishes and program terminates. Embedding a Wasm runtime must not violate WASI-compliancy of the whole QuickJS runtime. Most modern Wasm runtimes (such as WasmTime, WasmEdge, Wasmer, etc. ) are not WASI-compliant. A version of the WASMI runtime is WASI-compliant, and is well suited for use as the desired Wasm runtime. It will be understood that this particular Wasm runtime can be switched with a different WASI-compliant runtime, as all Wasm runtimes follow the same Wasm specification.

[0063] As shown in FIG. 1, a Wasm Interpreter Manager is also provided as part of the backend for the extended JavaScript runtime. The Wasm Interpreter Manager consists of two maps: (1) a module map, and (2) an instance map. In case of the former, when user loads a Wasm binary into a Module element, an entry is added to the module map, mapping an ID to the precompiled module for that binary. This enables low-cost module reusability for creating new instances. As for the instance map, whenever a living instance is created from a specific binary, it is pushed into the instance map and assigned an identifier. By providing Wasm instances with unique identifiers, when calling a function, it will be possible to ascertain what instance to pull from the instance map, run the function on it, and change its state.

[0064] Reference is made to FIG. 5 which shows an example OpenCV. js program capable of running in Wasm within the extended JavaScript runtime of the present disclosure. OpenCV (Open-Source Computer Vision Library) is an open-source computer vision and machine learning software library. OpenCV was built to provide a common infrastructure for computer vision applications and to accelerate the use of machine perception in the commercial products.

[0065] OpenCV. js is a JavaScript binding for a selected subset of OpenCV functions for the web platform. This binding uses a Wasm binary as the core part of the package that includes selected subset of OpenCV methods. Unlike the standard QuickJS runtime, the extended QuickJS with an embedded Wasm interpreter is able to work with this binding, enabling the users to run OpenCV code in Wasm.

[0066] FIG. 5 shows a program that performs an image dilation operation. All the cv. *calls are interacting with the Wasm instance through the embedded Wasm interpreter during the program execution. These interactions may include direct or indirect function invocation, reading from  / writing to Wasm memory space, and etc. To fully understand how the interactions are implemented, one would need to read OpenCV. js JavaScript binding. FIG. 6 shows some of these interactions. The code in top left corner shows the part in OpenCV. js where an instance is created from OpenCV Wasm binary through WebAssembly. instantiate () call. This call as depicted in FIG. 4 will push a new instance to the instance map list after linking imports to the Wasm runtime and creating JavaScript bindings for all different types of exports. Code shown in top right and bottom right respectively demonstrate creating references to Wasm memory and reading from them in JavaScript. These references will be used by host functions in JavaScript. Finally, the code in top left show how OpenCV pull dynamic functions from Wasm Tables and indirectly invoke them.

[0067] The methods and / or processes described above, and steps thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application. The hardware may include a general-purpose computer and / or dedicated computing device or specific computing device or particular aspect or component of a specific computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable devices, along with internal and / or external memory. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine-readable medium.

[0068] The computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.

[0069] Thus, in one aspect, each method described above, and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods may be embodied in systems that perform the steps thereof and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, the means for performing the steps associated with the processes described above may include any of the hardware and / or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

Claims

1.A computer-implemented method for extending a first JavaScript runtime, the method comprising:embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime:a runtime component that implements:a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; anda WebAssembly System Interface (WASI) -compliant Wasm runtime, anda Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.2.The method of claim 1, wherein the first JavaScript runtime comprises a WASI-compliant JavaScript interpreter.3.The method of claim 2, wherein the first JavaScript runtime comprises the QuickJS JavaScript engine.4.The method of claim 1, wherein embedding the Wasm interpreter within the first JavaScript runtime comprises integrating, in the first JavaScript runtime, an application programming interface (API) layer that implements a plurality of elements defined in a standard web API for Wasm JavaScript interface.5.The method of claim 4, wherein the plurality of elements of the standard web API for Wasm JavaScript interface include at least:a Memory object comprising a resizable memory buffer that defines Wasm memory spaces;a Global object representing a global variable instance that is accessible from JavaScript and Wasm;a Function object containing JavaScript functions that can be imported to Wasm or exported from it;a Table object comprising an array-like structure representing a Wasm table that stores homogeneous references;a Module object comprising a compiled Wasm binary within JavaScript code; andan Instance object containing exported Wasm functions.6.The method of claim 1, wherein the memory allocator is configured to handle memory growth for growing a number of pages within the memory space.7.The method of claim 1, wherein implementing the memory allocator comprises creating a JavaScript binding for a first memory space associated with a Wasm module that is loaded into a second memory space associated with the first JavaScript runtime.8.The method of claim 7, wherein implementing the memory allocator comprises shallow copying the first memory space associated with the Wasm module.9.The method of claim 1, wherein the runtime component further implements a function binder configured to create JavaScript bindings for exported functions that are defined within a Wasm module.10.The method of claim 9, wherein the function binder is configured to:detect a direct function invocation of an exported function; andin response to detecting the direct function invocation, serializing a function name and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.11.The method of claim 9, wherein the function binder is configured to:detect an indirect function invocation of an exported function; andin response to detecting the indirect function invocation, serializing a function pointer, table name, and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.12.The method of claim 1, wherein the runtime component further implements a context manager configured to provide references to states of Wasm instances.13.The method of claim 1, wherein the runtime component further implements an event loop scheduler configured to manage execution of one or more methods defined in a standard web API for Wasm JavaScript interface.14.The method of claim 1, wherein the runtime component further implements a type converter configured to convert JavaScript types to Wasm types and to convert Wasm results to JavaScript types.15.A computing system, comprising:a processor; anda memory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to extend a first JavaScript runtime executing on the processor, wherein extending the first JavaScript runtime comprises:embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime:a runtime component that implements:a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; anda WebAssembly System Interface (WASI) -compliant Wasm runtime, anda Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.16.The computing system of claim 15, wherein the first JavaScript runtime comprises a WASI-compliant JavaScript interpreter.17.The computing system of claim 16, wherein the first JavaScript runtime comprises the QuickJS JavaScript engine.18.The computing system of claim 15, wherein embedding the Wasm interpreter within the first JavaScript runtime comprises integrating, in the first JavaScript runtime, an application programming interface (API) layer that implements a plurality of elements defined in a standard web API for Wasm JavaScript interface.19.The computing system of claim 18, wherein the plurality of elements of the standard web API for Wasm JavaScript interface include at least:a Memory object comprising a resizable memory buffer that defines Wasm memory spaces;a Global object representing a global variable instance that is accessible from JavaScript and Wasm;a Function object containing JavaScript functions that can be imported to Wasm or exported from it;a Table object comprising an array-like structure representing a Wasm table that stores homogeneous references;a Module object comprising a compiled Wasm binary within JavaScript code; andan Instance object containing exported Wasm functions.20.The computing system of claim 15, wherein the memory allocator is configured to handle memory growth for growing a number of pages within the memory space.21.The computing system of claim 15, wherein implementing the memory allocator comprises creating a JavaScript binding for a first memory space associated with a Wasm module that is loaded into a second memory space associated with the first JavaScript runtime.22.The computing system of claim 21, wherein implementing the memory allocator comprises shallow copying the first memory space associated with the Wasm module.23.The computing system of claim 15, wherein the runtime component further implements a function binder configured to create JavaScript bindings for exported functions that are defined within a Wasm module.24.The computing system of claim 23, wherein the function binder is configured to:detect a direct function invocation of an exported function; andin response to detecting the direct function invocation, serializing a function name and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.25.The computing system of claim 23, wherein the function binder is configured to:detect an indirect function invocation of an exported function; andin response to detecting the indirect function invocation, serializing a function pointer, table name, and instance identifier of the exported function for binding to a native JavaScript function defined within the first JavaScript runtime.26.The computing system of claim 15, wherein the runtime component further implements a context manager configured to provide references to states of Wasm instances.27.The computing system of claim 15, wherein the runtime component further implements an event loop scheduler configured to manage execution of one or more methods defined in a standard web API for Wasm JavaScript interface.28.The computing system of claim 15, wherein the runtime component further implements a type converter configured to convert JavaScript types to Wasm types and to convert Wasm results to JavaScript types.29.A non-transitory, computer-readable medium storing processor-executable instructions that, when executed by a processor, configure the processor to extend a first JavaScript runtime executing on the processor, wherein extending the first JavaScript runtime comprises:embedding a WebAssembly (Wasm) interpreter within the first JavaScript runtime based on integrating, in the first JavaScript runtime:a runtime component that implements:a memory allocator configured to manage a memory space that is mutually accessible by Wasm and JavaScript; anda WebAssembly System Interface (WASI) -compliant Wasm runtime, anda Wasm interpreter manager configured to track compiled Wasm modules and instantiated Wasm modules.

Images