arXiv CSopen access

Bringing Managed Language Support to WebAssembly with External Library Linking

Bringing Managed Language Support to WebAssembly with External Library Linking

arXiv:2606.21919v1 [cs.SE] 20 Jun 2026

SHUYAO JIANG, The Chinese University of Hong Kong, China RUIYING ZENG, Fudan University, China YANGFAN ZHOU∗ , Fudan University, China MICHAEL R. LYU, The Chinese University of Hong Kong, China WebAssembly (Wasm) has emerged as a powerful bytecode format for running applications with near-native performance in portable and secure environments. However, while Wasm currently supports compiled languages like C, C++, and Rust, it lacks robust support for managed languages such as Python, Java, and JavaScript. This limitation hinders the deployment of applications in domains like machine learning and data processing that rely heavily on managed language ecosystems. To address this, we propose WALL-E, a novel framework to integrate managed languages into Wasm environments without complex runtime nesting or recompilation. WALL-E employs a unique external library linking strategy, using a client-server architecture to connect Wasm modules with managed language libraries running in their native runtimes. This approach preserves the native execution speed and language feature compatibility of managed languages by eliminating the overhead associated with double-layer virtual machines. Our evaluation shows that WALL-E supports ten managed languages without framework modifications and achieves a speedup of hundreds of times over the runtime nesting solution, with low communication overhead. WALL-E enhances the practicality of Wasm in cloud and edge computing, enabling efficient multi-language applications. CCS Concepts: • Software and its engineering → Software system models; Runtime environments; Software performance. Additional Key Words and Phrases: WebAssembly, Managed languages, Dynamic linking ACM Reference Format: Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu. 2026. Bringing Managed Language Support to WebAssembly with External Library Linking. Proc. ACM Softw. Eng. 3, FSE, Article FSE175 (July 2026), 24 pages. https://doi.org/10.1145/3808182

1

Introduction

WebAssembly (abbreviated Wasm) [25] is a binary instruction format designed as a compilation target for high-level programming languages. It was originally used for computationally intensive web applications and has been supported by all major browsers [74]. Wasm provides near-native speed, a memory-safe execution environment, cross-platform portability, and lightweight bytecode size. Such advantages also make Wasm increasingly popular outside the web. In recent years, Wasm ∗ Yangfan Zhou is the corresponding author.

Authors’ Contact Information: Shuyao Jiang, Department of Computer Science and Engineering, The Chinese University of Hong Kong, Hong Kong, China, [email protected]; Ruiying Zeng, College of Computer Science and Artificial Intelligence, Fudan University, Shanghai, China, [email protected]; Yangfan Zhou, College of Computer Science and Artificial Intelligence, Fudan University, Shanghai, China, [email protected]; Michael R. Lyu, Department of Computer Science and Engineering, The Chinese University of Hong Kong, Hong Kong, China, [email protected].

This work is licensed under a Creative Commons Attribution 4.0 International License. © 2026 Copyright held by the owner/author(s). ACM 2994-970X/2026/7-ARTFSE175 https://doi.org/10.1145/3808182 Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:2

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

has been widely adopted on many server-side applications, e.g., cloud computing [16, 17, 65], smart contracts [7, 75, 84], and microcontrollers [24, 81]. As Wasm gains popularity in various fields, a crucial issue for its future development is the capability of programming language support, i.e., enabling various programming languages to integrate with Wasm. Wasm is used as a compilation target, meaning that Wasm programs are not written by hand but compiled from high-level source languages. Therefore, to promote Wasm across more scenarios, it is essential to provide comprehensive language support for Wasm. However, the current language support for Wasm is still immature. The source languages that Wasm fully supports are limited, including some typical compiled languages, i.e., C, C++, and Rust [27]. But many other languages, especially managed languages (e.g., Python, Java, and JavaScript), still lack an effective mechanism for interacting with Wasm. As a result, a large number of existing applications written in different managed languages (e.g., machine learning applications in Python, database applications in Java) cannot be effectively deployed via Wasm, which is a critical bottleneck in the development of the Wasm ecosystem. The key challenge in bringing managed language support to Wasm is that the execution of such languages relies on their own managed runtimes, e.g., the Python interpreter. At the same time, Wasm programs also need to run on Wasm runtimes, e.g., WasmEdge [76]. Thus, to support the execution of a managed language in the Wasm context, it is inevitable for the Wasm runtime to handle the specific managed runtime of this source language (called external runtime). Unfortunately, there is still no satisfactory solution for Wasm to handle those external runtimes. The current mainstream mechanism is runtime nesting, which first compiles the external runtime (typically written in compiled languages such as C/C++) to Wasm bytecode and then runs it on the Wasm runtime, followed by executing the source program on that Wasm-formatted runtime [2]. This solution is intuitive but has several non-ignorable disadvantages. First, it is non-extensible for different source languages. Compiling the external runtime is a complex task that requires domain knowledge of the source language to ensure the correctness of the runtime functionality. So, it is hard to maintain the runtime compilation for different source languages and even different versions of the same source language. Second, it leads to poor performance, i.e., the program executes at a slow speed. This is obvious since runtime nesting introduces dual virtual environments, which increase system-level overhead during runtime, such as context switching and resource management. Third, the Wasmformatted runtime can only support limited language features. For example, python-wasmedge [2], a state-of-the-art solution that converts CPython [54] (a typical Python interpreter) to Wasm bytecode, still lacks support for many important Python packages. To address the challenge of external runtime handling, we propose a novel framework WALL-E (WAsm Language Linker via External Library) for bringing managed language support to Wasm. The key idea is external library linking: Take the target application written in a managed language (external language, e.g., Python) as an external library, which keeps the application running on its original runtime. Then, use a startup program written in a language natively supported by Wasm (native language, e.g., Rust) to link the external library dynamically. The premise of this design is that external libraries execute in a trusted environment. The Wasm module remains sandboxed, while the external execution is controlled by the trusted host runtime. Compared to the runtime nesting solution, our design has the following advantages: • Language extensibility: WALL-E does not require compiling the external runtimes into the Wasm format, so it is extensible to most external language without complicated maintenance. • High performance: WALL-E keeps external libraries running on their original runtimes, which can achieve a faster execution speed than the runtime nesting solution since it avoids much system-level overhead (e.g., context switch). Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:3

• Language feature compatibility: Without compiling the external runtimes into the Wasm format, WALL-E can leverage the original runtime ecosystems and thus support a broad set of language features of external languages. To implement WALL-E, we need to consider two critical issues. The first one is how to design the architecture of WALL-E to support the extensibility of programming languages. The second one is how to provide good usability, i.e., make it easy for users to use WALL-E. To achieve language extensibility, WALL-E adopts HTTP communication for external library linking since it is a universal communication protocol supported by any programming language. Specifically, WALL-E provides a startup program written in Rust as the HTTP client, and the target external library is encapsulated as the HTTP server. The client program is compiled into Wasm bytecode and runs on the Wasm runtime, and the server program runs on its original runtime as a web service. When starting library invocation, the client sends an HTTP request (including the data required by the target library) to the server to call the external library. Then, the server handles the request and returns the execution result of the target library to the client. To achieve good usability, WALL-E provides a unified interface to users for external library invocation. WALL-E also provides automatic server-side deployment, so users need only focus on client-side invocation logic. We conducted comprehensive experiments to evaluate the effectiveness of WALL-E. First, to evaluate the language extensibility, we apply WALL-E to link different types of external libraries written in ten popular managed languages. We showed that WALL-E is extensible across different managed languages and flexible to use in various applications. Second, to evaluate the performance of WALL-E, we compared the execution speed of WALL-E and the runtime nesting solution. We made the testing application run on the original runtime (our solution) and the Wasm-formatted runtime (the runtime nesting solution), then measured the execution speed of the application under both scenarios. The results indicated that WALL-E achieved hundreds of times faster execution speed than the runtime nesting solution. Third, we further measured the communication overhead of WALL-E and found that it accounts for only a small portion of the total process time. In summary, this work makes the following contributions: • Novel Concept: We present the first systematic study on managed language support for Wasm and introduce the innovative approach of external library linking to enable efficient integration of managed languages with Wasm. • Framework Design: We design and implement WALL-E, a practical framework that achieves managed language support in Wasm with multi-language extensibility, high performance, and broad language feature compatibility. • Comprehensive Evaluation: We apply WALL-E across multiple managed languages and conduct extensive experiments, demonstrating its effectiveness in real-world scenarios. 2 2.1

Background Wasm and Its Applications

WebAssembly (Wasm) [25] is a binary instruction format designed as a portable compilation target for high-level programming languages, enabling efficient execution on the web and beyond. Initially developed to complement JavaScript in browsers, Wasm provides near-native performance by leveraging a stack-based virtual machine optimized for speed, security, and compact bytecode [59]. Its sandboxed execution model ensures memory safety and platform independence, making it suitable for diverse environments. In browser-based applications, Wasm excels in performance-critical tasks such as game engines, multimedia processing, and scientific simulations, where JavaScript falls short in efficiency. For Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:4

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

Compiler

C/C++ Code

WASI

Wasmtime

Wasm Code

Wasm Runtime

Operating System

(a) Compiled Language: Workflow with C/C++ as the source language

WASI

Compiler

Python Code

Python Interpreter (e.g., CPython)

Wasmtime Wasm Code Wasm Runtime Nested Runtime

Operating System

(b) Managed Language: Workflow with Python as the source language Fig. 1. Current language support mechanism of Wasm for different types of programming languages.

instance, frameworks like Unity [73] and Unreal Engine [13] compile to Wasm to deliver highfidelity graphics in web applications. Beyond the browser, the advantages of Wasm have spurred its adoption in server-side environments, including cloud computing [29], edge computing [16], and serverless architectures [65]. Projects like Wasmtime [3] and WasmEdge [76] extend Wasm’s capabilities to standalone runtime environments, enabling developers to run Wasm modules on servers with low overhead and cross-platform compatibility. Given Wasm’s expanding role in both browser and server-side environments, its ability to provide high-performance support for multiple programming languages is crucial. This need becomes evident in modern platforms that execute third-party extensions inside a Wasm sandbox on the critical request path. A representative example is checkout-time customization logic (e.g., discounts, shipping, and payment rules) deployed as Wasm modules in e-commerce platforms. The platforms often enforce a strict latency budget (on the order of a few milliseconds) to avoid slowing down userfacing transactions [66]. In such settings, developers often wish to reuse mature managed language ecosystems (e.g., Python/JavaScript libraries for business rules, data processing, or lightweight analytics). However, supporting managed languages within the Wasm execution model remains non-trivial in practice. This motivates mechanisms for integrating managed languages into the Wasm ecosystem under tight latency and deployment constraints. 2.2

Language Support Mechanism of Wasm

Despite its growing ecosystem, the effectiveness of Wasm still hinges on robust support for diverse programming languages. While compiled languages like C/C++ and Rust have mature Wasm toolchains, many managed languages, those with garbage collection or dynamic typing (e.g., Python, Java), face challenges due to the linear memory model of Wasm and lack of built-in runtime features. We then discuss the language support mechanism of Wasm and how it motivates our work. Compiled Language Support. The execution of programs written in compiled languages (e.g., C, C++, Rust) to Wasm follows a well-defined toolchain-based workflow. Source code is first transformed into Wasm bytecode through language-specific compilers that target the Wasm Intermediate Representation (Wasm IR). A prominent example is Emscripten [80], an LLVM-based toolchain that Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:5

compiles C/C++ source code to optimized Wasm modules while generating necessary JavaScript glue code for browser integration. This glue code serves as a bridge between the compiled Wasm module and the browser’s JavaScript engine (e.g., V8 [21], SpiderMonkey [46]), handling memory management and facilitating system calls through standardized Web APIs. For non-browser environments, the WebAssembly System Interface (WASI) [8] specification provides a portable, capability-based security model for system interactions. WASI enables compiled Wasm modules to safely access operating system resources (file I/O, network sockets, etc.) while maintaining Wasm’s core security guarantees. Standalone Wasm runtimes (e.g., Wasmtime [3], Wasmer [78], and WasmEdge [76]) implement WASI, executing Wasm modules in isolated sandboxes with near-native performance. The typical workflow is as shown in Figure 1a. These runtimes employ advanced optimization techniques, including ahead-of-time (AOT) compilation and tiered just-in-time (JIT) compilation, to maximize execution efficiency. This robust support for compiled languages has made Wasm an attractive compilation target for performance-critical applications ranging from multimedia processing to scientific computing, while maintaining cross-platform compatibility and security. Managed Language Support. The design of Wasm as a low-level compilation target presents inherent challenges when executing programs written in managed languages (e.g., Python, JavaScript, and Java), due to their reliance on high-level runtime environments. Unlike compiled languages that can be directly translated into Wasm bytecode, managed languages require their runtime systems to execute properly. Current solutions attempt to address this through runtime nesting, a technique where the language’s runtime (typically implemented in a systems language like C) is first compiled into Wasm, allowing the source program to run on top of this Wasm-based runtime. Figure 1b shows the typical workflow with Python as the source language. Unfortunately, this solution introduces several fundamental limitations that constrain its practical application. First, the implementation is non-extensible. Porting a language runtime to Wasm requires deep expertise in both the source language implementation and the execution model of Wasm. Each new language or even version update demands significant engineering effort to recompile and validate the runtime, making the solution difficult to maintain and scale across different managed languages. Second, the performance is suboptimal, as the code must undergo multiple layers of interpretation, from the original language’s bytecode to Wasm bytecode and finally to machine code. This multi-level interpretation introduces substantial overhead. Third, the language feature support is limited, as many advanced features that rely on direct system interactions or native extensions cannot function properly within Wasm’s constrained execution environment. These limitations manifest clearly in specific language implementations. For Python, while CPython has been compiled to Wasm for executing Python code, the runtime nesting solution makes it difficult to support different Python versions or alternative implementations. Performance suffers due to the double interpretation layer, and critical Python packages are unsupported, as seen in the limited functionality of python-wasmedge [2]. JavaScript support similarly demonstrates these weaknesses. For example, WasmEdge’s integration of QuickJS [69] provides only basic JavaScript functionality and exhibits poor performance compared to native V8 execution. The challenges are most pronounced for Java, where no practical Wasm solution exists. The JVM’s complexity, with its JIT compilation, sophisticated garbage collection, and extensive native interfaces, makes it particularly difficult to adapt through runtime nesting. The inherent limitations of runtime nesting, including poor extensibility, performance overhead, and limited feature support, reveal the need for a fundamentally different approach to running managed languages on Wasm. Therefore, we attempt to design a novel mechanism that eliminates runtime nesting while achieving broad language support and native performance. Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:6

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu Client

Server Startup Program

Library File

+

Library Manager

Registration Metadata

Library Registration Wasm Code

Invocation Metadata

Python

Java

JavaScript

CPython

JVM

Node.js

Execution Result

…

External Library

…

External Runtime

Library Invocation

Wasm Runtime WASI

Operating System

Fig. 2. The framework design of WALL-E: A client-server architecture that registers and invokes external libraries via HTTP while executing library code in native runtimes.

3

WALL-E: Managed Language Support Framework for Wasm

To address the fundamental limitations of runtime nesting described above, we propose WALL-E, a framework for supporting managed languages for Wasm, based on the core idea of external library linking. WALL-E treats managed language applications (written in external language such as Python) as prepared external libraries that remain executing on their own runtimes, while a lightweight Wasm-native startup program (written in native language such as Rust) dynamically binds to and invokes these external libraries. Our design assumes that external libraries execute in trusted environments. The Wasm-side execution remains sandboxed, while the security properties of external execution rely on the host runtime and deployment controls. Compared to conventional runtime nesting, WALL-E is designed to improve: (1) Language extensibility, by avoiding recompilation of language runtimes into Wasm; (2) Execution performance, by eliminating nested-runtime interpretation and executing managed code in mature runtimes; and (3) Language feature compatibility, by leveraging the original runtime ecosystems without modifying the Wasm execution model. Figure 2 shows the overall framework design of WALL-E. To achieve language extensibility, the WALL-E framework implements a client-server architecture through standardized HTTP-based communication, chosen for its universal support across programming ecosystems. The workflow of WALL-E operates through multiple coordinated components. First, during the library registration phase (Section 3.1), the client user submits external library files accompanied by structured metadata descriptors, while the server infrastructure dynamically allocates network endpoints and instantiates managed service instances through a centralized library manager. The core library invocation phase (Section 3.2) uses a metadata-driven parameter marshaling mechanism: The client encodes invocation requests with explicit type annotations, and the external runtime reconstructs native values based on the declared types. Execution results are serialized and returned via HTTP channels, completing the cross-runtime invocation cycle. The implementation of WALL-E is based on the HTTP services provided by WasmEdge (Section 3.3). Overall, the architectural design of WALL-E ensures broad language extensibility through protocol standardization, and maintains Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:7

native execution performance by preserving original runtime contexts. Next, we will elaborate on the design and implementation details of WALL-E. 3.1

Library Registration

Before calling an external library, the user first needs to conduct library registration, i.e., provide the library files with a structured metadata to the library manager. Here, metadata refers to a JSON descriptor that specifies the library name, language, service endpoint, available function signatures (e.g., function name, parameters, and return type), and optional dependencies, which the library manager uses for service instantiation and invocation routing. The registration phase provides a centralized mechanism for validating and configuring external libraries before they can be invoked from Wasm. From a security standpoint, registration requires external libraries to be explicitly declared and added to an allowlist, helping prevent accidental invocation of undeclared endpoints. While Wasm modules remain sandboxed, external libraries execute in their native runtimes, and their security properties depend on the host environment and deployment controls rather than the Wasm sandbox itself. Accordingly, registration focuses on validating metadata and performing basic sanity checks prior to deployment, but it does not provide sandboxing for the external runtimes, which are assumed to be trusted in our deployment model. From the usability perspective, registration also decouples library deployment from invocation by automating service instantiation and endpoint allocation based on the submitted metadata. This separation reduces client-side configuration effort and provides a consistent interface for managing multiple external libraries. For a clearer description, we introduce the registration workflow from the perspectives of the client and the server, respectively. Client-Side Submission Process. The registration workflow begins with the client-side preparation of the external library. To simplify the user operation process, WALL-E provides a standardized startup program for end users. For library registration, the user only needs to provide two essential components to the library manager: • Library Source Code: The actual implementation files (e.g., Python modules, Java classes) containing the functional logic • Structured Metadata: A JSON descriptor specifying the operational characteristics of the provided library We choose JSON as the metadata description format due to its exceptional cross-language compatibility and universal support across programming ecosystems. This selection ensures that library metadata can be generated, parsed, and processed by both the client and server. For user convenience, WALL-E provides a template of the structured metadata. Based on the template, the user needs to declare the following fields of the library: "name", "language", "endpoint", "functions", and "dependencies". In particular, the "endpoint" field refers to the IP address of the external library as a web service, which can be auto-assigned by WALL-E or defined by the user. In the "functions" field, the user can declare multiple related functions, each of which should specify the "name", "params", and "return_type". Figure 3 shows an example registration metadata of a Python library named image-processor, providing various functional modules for image processing. In this example, we set the value of the "endpoint" field as "auto", indicating that WALL-E will automatically assign an IP address to this library. The client then sends a simple HTTP POST request to the /register endpoint of the library manager, using multipart form data to transmit both the code files and metadata simultaneously. This approach eliminates complex client-side configuration, requiring only minimal information from developers. Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:8

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

{

}

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

"name": "image-processor", "language": "python", "endpoint": "auto", // Server auto-assigns or user defines "functions": [ { "name": "enhance_contrast", "params": [ {"name": "input_image", "type": "ndarray"}, {"name": "enhancement_factor", "type": "float"} ], "return_type": "ndarray" } ], "dependencies": ["numpy", "opencv-python"]

Fig. 3. Example registration metadata of a Python library.

Server-Side Automated Deployment. Upon receiving a registration request, WALL-E initiates an automated deployment pipeline that transforms the client-submitted data into a runnable service. This process begins with a validation phase where the library manager verifies the metadata structure, ensuring all required fields (e.g., service name, language specification, and function definitions) are present and properly formatted. The library manager then performs basic sanity checks on the library code to flag disallowed access patterns. Concretely, the checks focus on validating the submitted package (e.g., rejecting path traversal patterns and invalid file layouts) and scanning for a limited set of filesystem/network access patterns inconsistent with the declared library configuration (e.g., attempts to access unavailable filesystem resources or initiate outbound network calls). These checks are intended to reduce obvious misconfigurations and unsafe patterns, rather than to provide sandboxing for external runtimes. Following successful validation, WALL-E proceeds to resource allocation, where it automatically assigns necessary network and computational resources. A unique service identifier is generated using UUID-based naming conventions (e.g., lib-python-a1b2c3), providing a distinct reference for the new library service. The deployment engine dynamically allocates available IP addresses and ports for the service to avoid endpoint conflicts. Based on the specified language requirements, the system can also configure computational resources (e.g., memory allocation and CPU limits) when supported by the deployment environment. When the resource is ready, WALL-E conducts service instantiation that executes language-specific initialization procedures. For example, for Python libraries, the deployment engine automatically creates a Flask [52] server scaffold with pre-configured endpoints including /invoke for function execution and /health for liveness checks. Similarly, for Node.js applications, the system configures an Express [51] server with appropriate middleware and routing structures. In our implementation, each service can be deployed in an isolated environment (e.g., a container) to separate external runtimes, while preserving the original runtime required for library execution. The deployment pipeline concludes with health check, where WALL-E monitors the newly instantiated service until it becomes responsive. Through periodic HTTP requests to the health check endpoint, the library manager verifies service responsiveness. This process ensures that only properly initialized and responsive services are registered in the discovery system, preventing incomplete deployments from affecting the overall system reliability. Upon a successful health check, the service is marked as active and becomes available for client-side invocations. Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

1 2 3 4 5 6 7 8

{

}

FSE175:9

"library_id": "lib-python-a1b2c3", "func": "enhance_contrast", "params": [ {"type": "ndarray", "value": "BASE64_ENCODED_DATA", "shape": [256, 256], "dtype": "float32"}, {"type": "float", "value": "1.5"} ]

Fig. 4. Example invocation metadata of a Python library.

3.2

Cross-Runtime Library Invocation

The library invocation process in WALL-E establishes a bridge between Wasm modules and external language runtimes through a client-server interaction model. Similar to the library registration workflow, the invocation process also follows a clear division between client-side request preparation and server-side execution management. A critical challenge in this phase is achieving cross-language parameter sharing, as different programming languages employ fundamentally different type systems and data representation formats that must be reconciled for successful interoperation. Thus, we design a parameter marshaling system for WALL-E to achieve automated parameter transformation between the client and the server. Client-Side Invocation Preparation. The invocation workflow begins with the client application preparing a structured invocation request containing all necessary information for cross-runtime execution. Since the target library has been registered as required, the information that the user needs to provide for invocation can be further simplified. The client constructs a JSON payload as the invocation metadata that specifies: • Target Identification: The unique service identifier ("library_id") obtained during library registration • Function Specification: The exact function name ("func") and parameter list ("params") for execution The request format maintains consistency with the registration metadata schema, creating a unified interface across both processes. Figure 4 provides an example of a typical invocation request targeting the Python library image-processor described in Section 3.1. In this example, the user aims to invoke the function enhance_contrast in the target library, with two parameters of type “ndarray” and “float”. This example demonstrates how WALL-E encapsulates the external language parameters from the client side. To enable seamless data exchange between disparate language runtimes, we employ a language-neutral parameter encoding strategy where all parameter values are represented as strings with explicit type annotations. For basic parameter types such as integers, floats, and strings, we utilize a straightforward string representation combined with an explicit value. A float value of 1.5, for instance, is encoded as {"type": "float", "value": "1.5"}, ensuring that both strongly-typed Wasm modules and dynamically-typed Python runtimes can reconstruct the original value. For complex parameter types that cannot be directly represented as JSON primitives (string/number/boolean), we use base64 encoding to preserve their byte-level representation. This mainly applies to raw binary payloads (e.g., image buffers or serialized objects) and numerical arrays (e.g., NumPy arrays). For example, for NumPy arrays, we encode the raw byte buffer using base64 and attach structural information, including the explicit shape and data type. A typical array Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:10

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

parameter might be encoded as {"type": "ndarray", "value": "BASE64_ENCODED_DATA", "shape": [256, 256], "dtype": "float32"}, where "BASE64_ENCODED_DATA" represents the actual base64-encoded string of the raw bytes. This approach enables the reconstruction of exact array structures on the server side, maintaining data integrity across the language boundary. The client subsequently transmits this structured JSON payload to the server’s /invoke endpoint via HTTP POST, initiating the cross-runtime library execution pipeline. Server-Side Request Processing. Upon receiving an invocation request, the server executes a multi-stage processing pipeline that ensures cross-runtime execution. This structured approach transforms client-submitted requests into actual function executions within the target language runtime with consistent request handling. The processing pipeline begins with service discovery, where the library manager resolves the provided library_id to the actual service endpoint using the centralized service registry. The library manager queries the database of the registered libraries to retrieve the complete service metadata, including the network endpoint, supported functions, and runtime characteristics. This service resolution mechanism provides an abstraction layer that enables dynamic service binding without client-side configuration. After successful service resolution, the library manager performs request forwarding where the original invocation request (including unprocessed parameters in their JSON format) is transparently sent to the target external runtime. The manager constructs an HTTP POST request to the /invoke endpoint of the external service, preserving all original parameters and metadata. This design ensures that each language runtime maintains full control over parameter parsing and validation, leveraging its native type system for accurate data conversion. The core execution occurs through distributed parameter processing where each external runtime independently handles parameter parsing and function invocation. Upon receiving the forwarded request, the embedded web server of the target runtime (e.g., Flask for Python, Express for Node.js) parses the JSON parameters using its native type system. Take Python as an example, this involves converting JSON representations into actual Python objects through the built-in parse_parameter() function, which handles base64-decoding of NumPy arrays, string-tonumber conversions, and other language-specific transformations. For user-defined Python classes, parse_parameter() attempts to resolve the declared type against class definitions in the registered library and reconstructs the object accordingly. If resolution fails or a mismatch occurs, the service returns an error message. This resolution relies on the consistency between the submitted library files and the type declarations in the metadata, but it does not require users to implement custom (un)marshaling logic on the client side. If parameter parsing succeeds, the runtime then executes the requested function with the properly typed parameters and captures the execution results. Finally, the process completes with result response where the external runtime returns the execution results to the library manager, which then forwards the final response to the client. The external runtime serializes the function return values using its native convert_result() mechanism, ensuring complex data types like NumPy arrays are properly encoded as base64 strings with appropriate metadata. The library manager acts as a transparent proxy, adding minimal overhead while providing request forwarding, optional logging, and a consistent response format across different language runtimes. 3.3

Implementation

The implementation of WALL-E leverages WasmEdge’s HTTP services [77] to provide the Wasm runtime environment for client-side operations, with Rust as the source language of the client-side startup program. Our implementation is built on WasmEdge 0.14.0 and Rust toolchain 1.27.1. We Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:11

select WasmEdge as the runtime framework for its excellent support for HTTP services, lightweight footprint, and high-performance execution, making it ideal for edge computing scenarios. The implementation uses WasmEdge’s async-enabled HTTP handler system to create an invocation gateway that receives JSON payloads from client applications, routes requests to appropriate external libraries, and serializes responses back to Wasm modules. We implement the user-submitted JSON metadata as a dynamically loaded configuration file, so updating library bindings only requires modifying the configuration without rebuilding the framework code. This runtime foundation ensures sandboxed client-side execution while maintaining low-latency communication with external language services through optimized HTTP protocols. It is worth noting that WALL-E is designed as a generic framework that can be implemented using various standalone Wasm runtimes beyond WasmEdge, providing flexibility for different deployment environments. 4

Evaluation

In this section, we evaluate the effectiveness of WALL-E in supporting managed languages within the Wasm environment. We aim to address the following research questions: • RQ1 (Language Extensibility): How extensible is WALL-E in supporting various managed languages without complex modifications? • RQ2 (Execution Performance): How does the execution speed of applications using WALLE compare to the existing runtime nesting solution? • RQ3 (Communication Overhead): What is the impact of the client-server communication on the performance of WALL-E? Experiment Environment. All our experiments are conducted on a server with a 2-core Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz and 16GB RAM. The operating system is 64-bit Ubuntu 24.04 LTS with the Linux kernel version 6.8.0-1009-aws. The experimental settings related to each RQ will be introduced in the following subsections. 4.1

RQ1: Language Extensibility

Settings. Given that language extensibility represents the most fundamental design criterion of WALL-E, our evaluation specifically targets this core capability through systematic testing across diverse programming languages. We selected the top 10 managed languages from The RedMonk Programming Language Rankings [58], representing diverse programming paradigms and runtime characteristics. The tested languages include JavaScript, Python, Java, PHP, C#, TypeScript, Ruby, R, Scala, and Kotlin. Each language was configured with its dominant web server framework, and tested on representative benchmarks and real-world applications to ensure a comprehensive evaluation of the language support capability of WALL-E. We first evaluate the language support capability of WALL-E on language-specific benchmarks using a measurable criterion. We report a pass rate for each language, defined as the fraction of benchmark programs that execute successfully through WALL-E and produce the expected output. To avoid bias in benchmark selection, we follow three principles: (1) Use public and widely recognized benchmark suites; (2) Use functionally similar workloads across languages to reduce language bias; and (3) The benchmarks can be executed independently without a complex harness, so that pass/fail outcomes can be directly observed. Based on these principles, we select benchmark programs from The Computer Language Benchmarks Game [18], which is widely used for comparing programming language performance across diverse computational tasks and provides implementations in more than twenty languages. For each language, we include all benchmark programs available for that language in the Benchmarks Game. We first execute these programs in a native local environment to establish a Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:12

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

Table 1. Managed languages for the language extensibility evaluation. Language* Wasm Support JavaScript Python Java PHP C# TypeScript Ruby R Scala Kotlin

% Limited % Limited Limited % Limited % % %

Runtime

Web Server

Application

Node.js v20.16.0 CPython 3.12.3 OpenJDK 21.0.8 PHP 8.3.10 .NET 8.0.117 Node.js v20.16.0 CRuby 3.2.0 R 4.3.3 Scala 3.5.0 Kotlin 2.0.10

Express Flask Spring Boot Slim-server ASP.NET Core Express Sinatra RestRserve Scalatra Javalin

Tesseract.js Face recognition Elasticsearch Image processing MsQuic Ajv validator FastImage ggplot2 GeoTrellis Kotlin serialization

* Ranked by The RedMonk Programming Language Rankings [58].

Table 2. Task overview in The Computer Language Benchmarks Game [18]. Task

Description

binary-trees fannkuch-redux fasta k-nucleotide mandelbrot n-body pidigits regex-redux reverse-complement spectral-norm

Allocate and deallocate binary trees Indexed-access to tiny integer-sequence Generate and write random DNA sequences Hashtable update and k-nucleotide strings Generate Mandelbrot set portable bitmap file Double-precision N-body simulation Streaming arbitrary-precision arithmetic Match DNA 8-mers and substitute magic patterns Read DNA sequences - write their reverse-complement Eigenvalue using the power method

baseline of runnable tests. Programs that pass locally are then deployed as services in WALL-E using the corresponding language-specific web server, and re-executed through WALL-E with the same standard inputs. This two-stage setup separates failures caused by language toolchain or environment issues from those introduced by WALL-E integration. A program is considered pass in WALL-E if it completes without errors and produces the expected output; otherwise, it is marked as fail (e.g., runtime error or output mismatch). We report the pass rate of WALL-E on locally runnable programs for each language as the primary measure of language support. In addition to the benchmark testing, we also configure each language with representative realworld applications as supplementary evidence of practical compatibility. These application-level experiments aim to assess WALL-E’s ability to integrate with common frameworks and deployment setups in practice, complementing the benchmark-based evaluation. Table 1 summarizes the 10 selected managed languages, including their current Wasm support status, runtime versions, representative web server frameworks, and applications used in our experimental setup. The “Limited” in the Wasm support status means that the source language can be supported by runtime nesting with limited language features. Table 2 overviews the computational tasks included in the benchmark suites, where each task has multiple implementation versions on each language. We next report the benchmark pass rates and application-level integration results of WALL-E for the evaluated languages. Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:13

Table 3. Benchmark pass rates on WALL-E across 10 managed languages. Language

#Runnable

#Passed

#Failed

Pass Rate

Failure Mode

JavaScript Python Java PHP C# TypeScript Ruby R Scala Kotlin

23 30 48 31 41 10 31 40 14 10

23 27 48 22 41 10 31 40 14 10

0 3 0 9 0 0 0 0 0 0

100% 90% 100% 70.97% 100% 100% 100% 100% 100% 100%

Runtime error Output mismatch -

Total

278

266

12

95.68%

from multiprocessing import Pool ... def multiply_AtAv(u): r = range(len(u)) tmp = pool.starmap(A_sum, zip(repeat(u), r)) return pool.starmap(At_sum, zip(repeat(tmp), r)) ... if __name__ == "__main__": with Pool(processes=4) as pool: main(int(sys.argv[1]))

(a) Benchmark snippet (spectralnorm_py_4.py)

# Flask service routing logic @app.route("/spectralnorm_py_4") def call_spectralnorm_py_4(): from python_benchmark.spectralnorm_py_4 import main from multiprocessing import Pool ... with Pool(processes=4) as pool: main(int(request.args.get("a"))) return "over\n"

(b) Service wrapper snippet (app.py)

Fig. 5. A representative Python failed case. The benchmark assumes a module-level pool initialized only under __main__, while the service wrapper creates a local Pool not visible to the imported module.

Results. Based on the benchmark suite, WALL-E achieves a high overall pass rate across the 10 managed languages. As shown in Table 3, out of 278 locally runnable tests, 266 pass when executed via WALL-E, achieving an overall pass rate of 95.68%. Eight languages (JavaScript, Java, C#, TypeScript, Ruby, R, Scala, and Kotlin) achieve a 100% pass rate on all their runnable tests. The remaining failures are concentrated in Python (27/30, 90%) and PHP (22/31, 70.97%). Overall, these results show that WALL-E can be empirically evaluated with measurable success criteria and observable negative outcomes, providing quantitative evidence of its language extensibility. We then conduct a detailed case analysis for the failed cases. Figure 5 shows a representative Python failed case spectralnorm_py_4, which raises “NameError: pool is not defined” when invoked as an HTTP endpoint. The root cause is that this benchmark relies on a module-level multiprocessing Pool that is initialized only inside the if __name__ == "__main__": block (shown in Figure 5a). When deployed as a long-running web service, the benchmark module is imported rather than executed as a script (shown in Figure 5b), so the __main__ initialization is bypassed and the global pool is never created. As a result, calls to pool.starmap(...) fail at runtime. The other two failed cases (spectralnorm_py_7 and mandelbrot_py_5) are also caused by a similar reason. This failure highlights a class of scripts that depend on global initialization, which requires a lightweight adapter (e.g., explicitly initializing such global resources in the service wrapper) when exposing them through our invocation interface. The nine failed PHP tests are represented by binarytrees_php_6 (shown in Figure 6), whose output differs from the local CLI baseline. This benchmark is implemented as a multi-process Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:14

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

function startWorker(...) { $pid = pcntl_fork(); ... } ... function waitWorkers(&$PIDs) { foreach ($PIDs as $PID) { $pid = pcntl_waitpid($PID, $status); } }

(a) Benchmark snippet (binarytrees_php_6.php)

$app->get('/binarytrees_php_6', function (...) { ... $workersPIDs = []; foreach ($depthIterations as $depth => $iter) { startWorker($depth, $iter, $workersPIDs,...); } waitWorkers($workersPIDs); ... return $response; });

(b) Service wrapper snippet (server.php)

Fig. 6. A representative PHP failed case. The benchmark relies on OS-level process management (e.g., pcntl_fork/pcntl_waitpid) to synchronize worker processes, which may be restricted in web services.

program: It uses pcntl_fork()/pcntl_waitpid() to spawn worker processes and relies on shared memory primitives to aggregate per-depth results. When deployed as a web service, such process control primitives are commonly restricted or disabled for safety and resource isolation, which can alter the program’s execution or aggregation behavior and introduce missing lines or runtime warnings in the output. As a result, the service response no longer matches the expected CLI output, leading to an output-mismatch failure under our correctness criterion. This case highlights that benchmarks that depend on OS-level process management may require adaptation (e.g.,, a single-process fallback) when exposed through an HTTP invocation interface. Beyond the benchmark suite, all selected real-world applications in Table 1 were successfully deployed and executed through WALL-E. These applications cover diverse domains, such as OCR processing (Tesseract.js), enterprise search (Elasticsearch), statistical visualization (ggplot2), and network operations (MSQuic). The results provide additional evidence that WALL-E can integrate practical workloads from multiple managed language ecosystems in realistic deployments. Summary of RQ1: WALL-E achieves broad language extensibility, reaching an overall benchmark pass rate of 95.68% across 10 managed languages and successfully deploying all representative real-world applications. 4.2

RQ2: Execution Performance

Settings. Since enhancing the execution performance of managed languages is also a crucial design objective for WALL-E, we conducted a comprehensive evaluation to compare the runtime performance of various applications between WALL-E and the existing runtime nesting solution. We selected Python as the target language, as it represents a typical managed language with significant runtime overhead. The baseline for comparison is the python-wasmedge runtime developed by VMware Labs [34], an authoritative implementation that provides Python runtime capabilities within Wasm through runtime nesting techniques. To ensure a fair comparison, we maintained identical software versions (WasmEdge 0.14.0 and Python 3.12) across both environments. It is worth noting that RQ2 reports the execution time of benchmark code measured inside the Python runtime, excluding the client-server communication overhead introduced by WALL-E. We evaluate such end-to-end overhead separately in RQ3. In terms of benchmark selection, we initially attempted to use the standard Python performance test suite PyPerformance [57] to ensure comparability with established practices. However, we encountered a fundamental limitation: The test suite relies on packages that currently lack WASI support and therefore cannot execute within the python-wasmedge runtime. This constraint Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:15

Table 4. Execution time statistics of Python benchmarks on python-wasmedge and WALL-E (in seconds). Compute-intensive Tasks

I/O-intensive Tasks

Memory-intensive Tasks

BM

PY-WE*

WALL-E

↑×

BM

PY-WE

WALL-E

↑×

BM

PY-WE

WALL-E

↑×

pystone nqueens prime matrix fibonacci

96.551 765.146 8.332 70.985 1377.160

0.129 1.434 0.010 0.074 1.934

748 553 833 959 712

file json text list dict

0.241 13.325 22.534 84.755 16.701

0.002 0.026 0.050 0.153 0.043

120 512 450 553 388

alloc string large object recur

66.194 1.207 39.322 118.213 1.068

0.184 0.002 0.080 0.319 0.002

359 603 491 370 534

Avg.

463.635

0.716

647

Avg.

27.511

0.055

500

Avg.

45.201

0.117

386

* PY-WE refers to python-wasmedge.

Table 5. Execution time statistics of real-world Python libraries (in seconds). jsonschema (𝑛=1024)

markdown (𝑛=256)

Chunk (𝑘)

PY-WE

WALL-E

↑×

Chunk (𝑘)

PY-WE

WALL-E

↑×

1 8 32

63.251 63.100 63.840

0.097 0.090 0.089

652 701 717

1 8 32

99.566 98.929 103.344

0.225 0.218 0.228

443 454 453

Avg.

63.397

0.092

689

Avg.

100.613

0.224

449

𝑛: total inputs (docs for jsonschema, texts for markdown). 𝑘: number of chunks/invocations (total input size 𝑛 is fixed).

prevented the use of standardized benchmark suites and necessitated the creation of a custom benchmark dataset. To address this challenge, we constructed a benchmark suite consisting of 15 distinct tests covering three major workload categories: • Compute-intensive Tasks: Pystone, N-Queens problem solving, Prime number calculation, Matrix multiplication, Fibonacci sequence computation • I/O-intensive Tasks: File I/O, JSON serialization/deserialization, Text processing, List comprehensions, Dictionary operations • Memory-intensive Tasks: Memory allocation, String manipulations, Large data structure creation, Object instantiation, Recursive structure processing In addition to the micro-benchmarks above, we further include two real-world Python libraries to assess WALL-E on practical software and non-trivial interaction patterns. Specifically, we evaluate JSON schema validation using jsonschema [55] and Markdown rendering using markdown [56]. For jsonschema, we validate a dataset of 𝑛=1024 documents; for markdown, we render 𝑛=256 Markdown inputs. To model non-trivial interactions beyond a single call, we vary the invocation granularity by splitting each workload into 𝑘 ∈ 1, 8, 32 chunks and invoking the external runtime 𝑘 times per run, while keeping the total input size 𝑛 fixed. This setup enables us to study both execution performance under realistic application logic and the impact of repeated cross-runtime invocations under the same workload. For each workload (including micro-benchmarks and real-world libraries), we run it 10 times in both environments and report the average execution time, excluding the first run to reduce initialization effects. This setting provides a consistent basis for comparison under the package and WASI constraints of the python-wasmedge runtime.

Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:16

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

Results. Table 4 presents a detailed comparison of the execution time of the Python benchmarks run on both python-wasmedge and WALL-E. For each benchmark, the table records the average execution time and calculates the speedup (↑ ×) achieved by WALL-E . The results reveal that WALLE delivers significant performance enhancements across all categories, with the most significant gains in compute-intensive tasks (average 647× speedup), followed by I/O-intensive (500×) and memory-intensive (386×) operations. This performance hierarchy directly reflects the cumulative overhead imposed by the nested runtime architecture of python-wasmedge. The exceptionally high speedups in computational tasks like “matrix” (959×) and “prime” (833×) highlight the tremendous cost of double virtualization on pure CPU operations, while the cost is also significant for I/O tasks and memory-intensive operations. Table 5 reports the execution time of two real-world Python libraries. WALL-E consistently outperforms python-wasmedge by large margins across all chunk settings. For jsonschema (𝑛=1024), WALL-E achieves 689× speedup on average. For markdown (𝑛=256), the average speedup is 449×. Notably, varying the chunk number (𝑘 ∈ 1, 8, 32) does not materially change the execution time within each environment, indicating that the dominant factor is the underlying execution stack rather than the invocation granularity. These performance gaps are directly attributable to their fundamental architectural differences. The python-wasmedge runtime uses a nested architecture, incurring substantial overhead from nested execution and cross-boundary transitions. In contrast, WALL-E executes the workload in the native Python runtime instead of embedding the interpreter into Wasm. The execution is triggered via network communication through its client, which invokes the native Python runtime as an external service. As a result, WALL-E avoids the nested-runtime overhead and achieves consistently lower execution times across workloads. Summary of RQ2: WALL-E substantially outperforms python-wasmedge by avoiding nested-runtime execution. Across micro-benchmarks, WALL-E achieves average speedups of 647×, 500×, and 386× for three workload categories. On real-world libraries, WALL-E delivers 689× (jsonschema) and 449× (markdown) speedups on average. 4.3

RQ3: Communication Overhead

Settings. The client-server architecture of WALL-E inherently introduces communication overhead due to the HTTP-based interaction between Wasm modules and external runtimes. To quantitatively evaluate the impact of this overhead on overall performance, we conducted a fine-grained time analysis of the complete external library invocation process. As illustrated in Figure 7, the invocation workflow is decomposed into seven distinct phases: (1) configuration loading on the client side, (2) external library invocation, (3) HTTP request transmission, (4) parameter parsing on the server, (5) function execution, (6) response serialization, and (7) HTTP response transmission. To measure the duration of each phase, we conducted instrumentation within the framework source code. We inserted timestamps before and after each critical operation, ensuring microsecondlevel precision. This instrumentation strategy allowed us to capture the exact time consumption of each processing stage without significantly affecting the overall system performance. A key consideration involves the measurement of network transmission time, which spans both client and server environments. We observed that the client-measured external library invocation period (➁) actually includes all the subsequent phases (➂~➆). Therefore, rather than attempting synchronized cross-runtime timing, we calculated the network duration (➂+➆) by subtracting the total server-side processing time (➃+➄+➅) from the external library invocation time (➁). This approach eliminates the need for clock synchronization while providing accurate estimates of network latency. Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:17

Fig. 7. The complete external library invocation process in WALL-E. Table 6. Communication overhead statistics across Python benchmarks (in milliseconds). BM

Ttotal

Texec

Oclient

Onetwork

Oserver

Ototal

pystone nqueens prime matrix fibonacci

131.725 (100%) 1442.345 (100%) 13.553 (100%) 78.456 (100%) 1905.187 (100%)

129.706 (98.47%) 1440.165 (99.85%) 11.434 (84.37%) 76.341 (97.30%) 1902.936 (99.88%)

0.134 (0.10%) 0.235 (0.02%) 0.135 (1.00%) 0.146 (0.19%) 0.140 (0.01%)

1.794 (1.36%) 1.837 (0.13%) 1.870 (13.80%) 1.852 (2.36%) 2.013 (0.11%)

0.091 (0.07%) 0.108 (0.01%) 0.114 (0.84%) 0.117 (0.15%) 0.108 (0.01%)

2.019 (1.53%) 2.180 (0.15%) 2.119 (15.63%) 2.115 (2.70%) 2.261 (0.12%)

Avg.

714.253 (100%)

712.116 (99.70%)

0.158 (0.02%)

1.873 (0.26%)

0.108 (0.02%)

2.139 (0.30%)

Ttotal =𝑇 (➀+➁), Texec =𝑇 (➄), Oclient =𝑇 (➀), Onetwork =𝑇 (➂+➆), Oserver =𝑇 (➃+➅), Ototal =Oclient +Onetwork +Oserver .

Table 7. Communication overhead statistics of real-world Python libraries (in milliseconds). jsonschema

Ttotal

Texec

Ototal

markdown

Ttotal

Texec

Ototal

𝑘=1 𝑘=8 𝑘=32

103.846 101.871 97.963

91.986 90.767 86.325

11.860 (11.42%) 11.104 (10.90%) 11.638 (11.88%)

𝑘=1 𝑘=8 𝑘=32

226.736 223.549 222.045

221.805 218.172 217.217

4.931 (2.17%) 5.377 (2.41%) 4.828 (2.17%)

Avg.

101.227

89.693

11.534 (11.39%)

Avg.

224.110

219.065

5.045 (2.25%)

For overhead analysis, we consider all phases except the actual function execution (➄) as the total communication-related overhead. This includes configuration loading, parameter serialization and deserialization, network transmission, and response processing. The proportional contribution of these overhead components to the entire process time (➀+➁) serves as the primary metric for evaluating the efficiency of the cross-language communication mechanism of WALL-E. Results. Our experimental results reveal a consistent pattern of communication overhead across all tests in WALL-E. Due to space constraints, we present detailed results only for compute-intensive benchmarks in Table 6, which show that the total communication overhead remains low, averaging only 0.30% of the total process time. The overhead distribution is consistent across different workloads. Network transmission constitutes the dominant overhead component, accounting for 0.26% on average. Client-side processing overhead remains negligible at 0.02%, consisting of configuration loading and parameter serialization. Server-side overhead is also minimal at 0.02%, including parameter parsing and response serialization. The actual function execution time accounts for 99.70% of the total process time on average, indicating that the vast majority of time is spent on productive computation rather than on framework overhead. Table 7 further reports overhead statistics for the real-world libraries. On average, the communication overhead accounts for 11.39% of the total time for jsonschema and 2.25% for markdown, and the overhead ratios remain stable across 𝑘 ∈ {1, 8, 32}. The overhead for jsonschema is higher because each run involves larger request/response payloads (a schema plus 𝑛=1024 JSON documents), leading to more expensive data serialization, transmission, and JSON parsing than markdown Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:18

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

(𝑛=256 texts). Despite this increase, the overhead remains acceptable in practice, especially given the substantial execution-time improvements observed in RQ2. Summary of RQ3: WALL-E incurs low communication overhead overall. It accounts for 0.30% of total time on micro-benchmarks, and remains modest on real-world workloads (11.39% for jsonschema and 2.25% for markdown), indicating that cross-language invocation costs are generally small relative to execution time.

5 5.1

Discussion Limitations

WALL-E currently supports invoking external libraries initiated from Wasm programs, but it does not support callbacks from external runtimes back into Wasm. This limitation arises from our design goal of enabling a simple and extensible external library linking mechanism, in which Wasm programs act as clients that invoke external libraries using a request-response interaction pattern. Supporting callbacks would require a more tightly coupled and bidirectional execution model across runtimes, which is beyond the scope of the current design of WALL-E. Consequently, WALL-E is best suited for scenarios with clearly defined library boundaries, while integration patterns that rely heavily on callbacks or event-driven interactions are not directly supported. WALL-E assumes that external libraries execute in trusted managed language runtimes outside the Wasm sandbox. While the Wasm-side orchestration logic remains sandboxed, the execution of external libraries relies on the security mechanisms provided by the host environment. This design shifts the security boundary compared to approaches that compile managed runtimes entirely into Wasm and therefore inherit Wasm’s sandbox guarantees. As a result, WALL-E is most appropriate for controlled deployment settings, such as internal services or trusted library integration, rather than for scenarios involving untrusted third-party code. Although WALL-E avoids the complexity of runtime nesting and execution model extensions, it introduces additional usability challenges at the developer level. Developers must reason about cross-language interfaces, parameter marshaling, and error propagation across different runtimes, which can increase cognitive load and complicate debugging. To mitigate these challenges, WALL-E is designed to minimize client-side development effort by providing unified invocation interfaces, structured metadata, and automated cross-runtime communication. Nevertheless, cross-language integration inherently requires additional coordination across execution environments, and this usability trade-off may still affect development experience in complex integration scenarios. 5.2

Threats to Validity

The first threat relates to the generalizability of WALL-E’s external library linking design, which may not accommodate all types of application scenarios. To maximize generality, we adopted standard HTTP RESTful interfaces to ensure protocol compatibility and utilized JSON as the primary data serialization format for its widespread support across programming ecosystems. While this design may not be optimal for all use cases, it provides a robust foundation for the majority of cross-language invocation scenarios encountered in practice. The second threat concerns the potential limitations in language extensibility evaluation due to constrained test case coverage. To mitigate this threat, we based our language selection on the RedMonk rankings to include mainstream programming languages that represent different computational paradigms. Our evaluation encompassed diverse runtime characteristics, ensuring Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:19

that our findings reflect the extensibility of WALL-E across a wide spectrum of managed language environments, though certain niche or emerging languages may require additional validation. The third threat involves potential biases in performance evaluation, including baseline selection and benchmark construction. We mitigated this concern by choosing the representative python-wasmedge runtime as our baseline to ensure credibility. Due to functional limitations of the baseline environment, we constructed a dataset that maintains functional equivalence while ensuring executability in both test environments. Our dataset incorporates diverse workload types and employs statistical methods to ensure the reliability of our performance comparisons. 6

Related Work

Wasm Runtime Features. Wasm has attracted a lot of research interest as a promising technique since it was initially introduced [26, 37, 71]. It has been widely applied on both the web side [30, 59, 61] and the server side [16, 43, 50] in recent years. To make Wasm better adapted to various application scenarios, many studies aim at analyzing and improving Wasm runtime features, including safety [6, 19, 33, 35], efficiency [31, 32, 39, 62, 82], lightweight [44, 47, 63], etc. Among existing research on Wasm runtime features, safety is the most compelling aspect [83]. Lehmann et al. [35] first studied the vulnerabilities in Wasm binaries, and provided a set of vulnerable applications along with end-to-end exploits. Narayan et al. designed Swivel [48], a new compiler framework for hardening Wasm against Spectre attacks. Runtime efficiency is another key feature widely studied for Wasm. Titzer introduced a fast in-place Wasm interpreter [72], which improves the runtime efficiency by compiling Wasm to machine code without rewriting or a separate format. Moron et al. [45] presented a microcontroller-compatible Wasm runtime that supports JIT compilation to improve the execution speed. In addition, lightweight Wasm runtimes are also an attractive direction. For example, Sledge [17] is a lightweight Wasm-based serverless framework optimized for low startup time, bursty client request rates, and short-lived computations. As Wasm is a compilation target for programming languages, the language support capability is also a key feature to consider. However, Wasm’s current language support is still immature, especially for managed languages [27]. Managed Language Support in Wasm. Supporting managed languages in Wasm remains challenging due to their reliance on complex runtime systems. A common line of work adopts runtime nesting, in which the language runtime is first compiled to Wasm, allowing source programs to execute on that Wasm-based runtime. Representative examples include Python WASI support [34], and lightweight JavaScript engines such as QuickJS [69]. While runtime nesting enables basic execution of managed languages within Wasm environments, prior studies have observed limitations in extensibility, performance, and compatibility with language features. More recently, the Wasm community has explored extending the execution model itself to better accommodate managed languages. The WebAssembly Garbage Collection (WasmGC) proposal [20] introduces better support for garbage-collected objects and typed references, enabling managed languages to be compiled more directly to Wasm without embedding an entire language runtime. However, WasmGC-based approaches rely on dedicated compiler support and GC-enabled Wasm engines, and their applicability depends on the availability and maturity of such runtimes in target deployment environments [23, 70]. Such reliance may limit its applicability in environments where modifying or upgrading the Wasm execution stack is undesirable. Dynamic Linking. Beyond extending the Wasm execution model, dynamic linking [15, 28] is another alternative mechanism. It is a technique for linking software libraries to target programs at execution time, offering benefits such as code reuse, library updates without source modification, and enhanced security through address space randomization [64]. Many existing studies adopt Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:20

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

dynamic linking techniques to optimize software systems [4, 9, 10, 12]. For example, Dunkels et al. [12] implemented an in-situ run-time dynamic linker and loader for reprogramming resourceconstrained wireless sensor nodes. Dong et al. [10] further proposed a holistic dynamic linking and loading mechanism in networked embedded systems for minimal code size, efficient runtime speed, and kernel-user isolation. There are also extensive studies devoted to providing better algorithms and architectures for dynamic linking [1, 5, 42, 60]. In the Wasm community, dynamic linking has been applied for function extension and performance optimization [36, 40, 41]. Wasm programs are organized into modules, which can be dynamically linked to create modular applications. Mäkitalo et al. [40] presented a dynamic linking system for Wasm modules and studied its performance. Wen et al. introduced WasmSlim [79], which transforms Wasm into a slim main module and dynamically linked secondary modules to reduce binary size and improve startup speed. HTTP-Based Cross-Language Invocation. A substantial body of prior work adopts HTTPbased invocation as a practical mechanism for cross-language integration [22, 38, 67]. Widely used frameworks such as FastAPI for Python [14] and Spring Boot for Java [68] enable languagespecific libraries and services to be exposed through RESTful APIs, allowing clients written in other languages to invoke them via standard HTTP interfaces. Beyond individual frameworks, HTTP and RPC-based cross-language invocation has been extensively studied in the context of service-oriented architectures and microservices [11, 49, 53], where language-agnostic communication protocols serve as the foundation for polyglot systems. These approaches typically assume independently deployed services and focus on coarse-grained service invocation across language boundaries. In the context of Wasm, this work explores leveraging HTTP-based invocation to integrate managed-language libraries with Wasm programs. In this setting, HTTP serves not merely as a general-purpose service interface, but as an enabling mechanism for dynamically linking external libraries to Wasm modules at runtime. This positioning distinguishes HTTP-based invocation in the Wasm setting from its traditional role in microservice architectures and motivates its use as a lightweight alternative to runtime nesting or execution-model extensions. 7

Conclusion

This paper presents WALL-E, a novel framework that addresses the critical challenge of managed language support in Wasm through external library linking. Unlike existing runtime nesting approaches that suffer from limited language compatibility and performance overhead, WALL-E introduces a client-server architecture that keeps the Wasm module sandboxed while enabling efficient integration with diverse language runtimes. Our evaluation demonstrates that WALL-E successfully supports ten managed languages without framework modifications, achieves near-native execution performance with low communication overhead. This work establishes a foundation for multi-language edge computing and opens new directions for performance optimization and cloud-native deployment in Wasm ecosystems. Data Availability Our source code and experiment data are available at https://figshare.com/s/5da0d15030538b69fcca. Acknowledgments This work was supported by the National Natural Science Foundation of China (Project No. 62572127), the Research Grants Council of the Hong Kong Special Administrative Region, China (No. CUHK 14209124 of the General Research Fund), and RGC Grant for Theme-based Research Scheme Project (RGC Ref. No. T43-513/23-N). Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:21

References [1] Varun Agrawal, Abhiroop Dabral, Tapti Palit, Yongming Shen, and Michael Ferdman. 2015. Architectural support for dynamic linking. In Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems. 691–702. doi:10.1145/2694344.2694392 [2] Asen Alexandrov. 2023. Adding Python WASI support to Wasm Language Runtimes. https://wasmlabs.dev/articles/ python-wasm32-wasi/. [3] Bytecode Alliance. 2025. Wasmtime. https://github.com/bytecodealliance/wasmtime. [4] Anil Altinay, Joseph Nash, Taddeus Kroes, Prabhu Rajasekaran, Dixin Zhou, Adrian Dabrowski, David Gens, Yeoul Na, Stijn Volckaert, Cristiano Giuffrida, et al. 2020. BinRec: dynamic binary lifting and recompilation. In Proceedings of the Fifteenth European Conference on Computer Systems. 1–16. doi:10.1145/3342195.3387550 [5] Sean Bartell, Will Dietz, and Vikram S Adve. 2020. Guided linking: dynamic linking without the costs. Proceedings of the ACM on Programming Languages 4, OOPSLA (2020), 1–29. doi:10.1145/3428213 [6] Jay Bosamiya, Wen Shih Lim, and Bryan Parno. 2022. {Provably-Safe} multilingual software sandboxing using {WebAssembly}. In 31st USENIX Security Symposium (USENIX Security 22). 1975–1992. https://www.usenix.org/ conference/usenixsecurity22/presentation/bosamiya [7] Weimin Chen, Zihan Sun, Haoyu Wang, Xiapu Luo, Haipeng Cai, and Lei Wu. 2022. WASAI: uncovering vulnerabilities in Wasm smart contracts. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 703–715. doi:10.1145/3533767.3534218 [8] Lin Clark. 2019. Standardizing WASI: A system interface to run WebAssembly outside the web. Mozilla Hacks–the Web developer blog (2019). https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ [9] Bjorn De Sutter, Bruno De Bus, and Koen De Bosschere. 2005. Link-time binary rewriting techniques for program compaction. ACM Transactions on Programming Languages and Systems (TOPLAS) 27, 5 (2005), 882–945. doi:10.1145/ 1086642.1086645 [10] Wei Dong, Chun Chen, Xue Liu, Jiajun Bu, and Yunhao Liu. 2009. Dynamic linking and loading in networked embedded systems. In 2009 IEEE 6th international conference on mobile adhoc and sensor systems. IEEE, 554–562. doi:10.1109/mobhoc.2009.5336957 [11] Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara, Fabrizio Montesi, Ruslan Mustafin, and Larisa Safina. 2017. Microservices: yesterday, today, and tomorrow. Present and ulterior software engineering (2017), 195–216. doi:10.1007/978-3-319-67425-4_12 [12] Adam Dunkels, Niclas Finne, Joakim Eriksson, and Thiemo Voigt. 2006. Run-time dynamic linking for reprogramming wireless sensor networks. In Proceedings of the 4th international conference on Embedded networked sensor systems. 15–28. doi:10.1145/1182807.1182810 [13] Unreal Engine. 2025. Unreal Engine. https://www.unrealengine.com/. [14] FastAPI. 2025. FastAPI. https://fastapi.tiangolo.com/. [15] Michael Franz. 1997. Dynamic linking of software components. Computer 30, 3 (1997), 74–81. doi:10.1109/2.573670 [16] Philipp Gackstatter, Pantelis A Frangoudis, and Schahram Dustdar. 2022. Pushing serverless to the edge with webassembly runtimes. In 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid). IEEE, 140–149. doi:10.1109/ccgrid54584.2022.00023 [17] Phani Kishore Gadepalli, Sean McBride, Gregor Peach, Ludmila Cherkasova, and Gabriel Parmer. 2020. Sledge: A serverless-first, light-weight wasm runtime for the edge. In Proceedings of the 21st international middleware conference. 265–279. doi:10.1145/3423211.3425680 [18] Benchmarks Game. 2018. The Computer Language Benchmarks Game. https://benchmarksgame-team.pages.debian. net/benchmarksgame/. [19] Adam T Geller, Justin Frank, and William J Bowman. 2024. Indexed Types for a Statically Safe WebAssembly. Proceedings of the ACM on Programming Languages 8, POPL (2024), 2395–2424. doi:10.1145/3632922 [20] Google. 2023. A new way to bring garbage collected programming languages efficiently to WebAssembly. https: //v8.dev/blog/wasm-gc-porting. [21] Google. 2025. V8 JavaScript Engine. https://v8.dev/. [22] Matthias Grimmer, Roland Schatz, Chris Seaton, Thomas Würthinger, Mikel Luján, and Hanspeter Mössenböck. 2018. Cross-language interoperability in a multi-language runtime. ACM Transactions on Programming Languages and Systems (TOPLAS) 40, 2 (2018), 1–43. doi:10.1145/3201898 [23] Safia Guellil and Marc Sánchez-Artigas. 2025. Optimizing WebAssembly Garbage Collection in Go: Performance Insights, Tuning Tips, and Batch Execution Strategies. In 2025 IEEE 45th International Conference on Distributed Computing Systems (ICDCS). IEEE, 670–680. doi:10.1109/icdcs63083.2025.00071 [24] Robbert Gurdeep Singh and Christophe Scholliers. 2019. WARDuino: a dynamic WebAssembly virtual machine for programming microcontrollers. In Proceedings of the 16th ACM SIGPLAN International Conference on Managed Programming Languages and Runtimes. 27–36. doi:10.1145/3357390.3361029 Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:22

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

[25] Andreas Haas, Andreas Rossberg, Derek L Schuff, Ben L Titzer, Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and JF Bastien. 2017. Bringing the web up to speed with WebAssembly. In Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation. 185–200. doi:10.1145/3062341.3062363 [26] Ningyu He, Zhehao Zhao, Jikai Wang, Yubin Hu, Shengjian Guo, Haoyu Wang, Guangtai Liang, Ding Li, Xiangqun Chen, and Yao Guo. 2023. Eunomia: enabling user-specified fine-grained search in symbolically executing WebAssembly binaries. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 385–397. doi:10.1145/3597926.3598064 [27] Aaron Hilbig, Daniel Lehmann, and Michael Pradel. 2021. An empirical study of real-world webassembly binaries: Security, languages, use cases. In Proceedings of the Web Conference 2021. 2696–2708. doi:10.1145/3442381.3450138 [28] W Wilson Ho and Ronald A Olsson. 1991. An approach to genuine dynamic linking. Software: Practice and Experience 21, 4 (1991), 375–390. doi:10.1002/spe.4380210404 [29] Shashank Mohan Jain and Shashank Mohan Jain. 2022. Extending Istio with WebAssembly. WebAssembly for Cloud: A Basic Guide for Wasm-Based Cloud Apps (2022), 151–160. doi:10.1007/978-1-4842-7496-5_8 [30] Abhinav Jangda, Bobby Powers, Emery D Berger, and Arjun Guha. 2019. Not so fast: Analyzing the performance of {WebAssembly} vs. native code. In 2019 USENIX Annual Technical Conference (USENIX ATC 19). 107–120. https: //www.usenix.org/conference/atc19/presentation/jangda [31] Shuyao Jiang, Ruiying Zeng, Zihao Rao, Jiazhen Gu, Yangfan Zhou, and Michael R. Lyu. 2023. Revealing Performance Issues in Server-side WebAssembly Runtimes via Differential Testing. In Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 661–672. doi:10.1109/ase56229.2023.00088 [32] Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu. 2025. Distinguishability-guided Test Program Generation for WebAssembly Runtime Performance Testing. In Proceedings of the 32nd IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 768–779. doi:10.1109/saner64311.2025.00078 [33] Evan Johnson, Evan Laufer, Zijie Zhao, Dan Gohman, Shravan Narayan, Stefan Savage, Deian Stefan, and Fraser Brown. 2023. WaVe: a verifiably secure WebAssembly sandboxing runtime. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2940–2955. doi:10.1109/sp46215.2023.10179357 [34] VMware Labs. 2025. WebAssembly Language Runtimes. https://github.com/vmware-labs/webassembly-languageruntimes. [35] Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020. Everything old is new again: Binary security of {WebAssembly}. In 29th USENIX Security Symposium (USENIX Security 20). 217–234. https://www.usenix.org/ conference/usenixsecurity20/presentation/lehmann [36] Daniel Lehmann and Michael Pradel. 2019. Wasabi: A framework for dynamically analyzing webassembly. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems. 1045–1058. doi:10.1145/3297858.3304068 [37] Daniel Lehmann, Michelle Thalakottur, Frank Tip, and Michael Pradel. 2023. That’s a Tough Call: Studying the Challenges of Call Graph Construction for WebAssembly. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 892–903. doi:10.1145/3597926.3598104 [38] Li Li, Wu Chou, Wei Zhou, and Min Luo. 2016. Design patterns and extensibility of REST API for networking applications. IEEE Transactions on Network and Service Management 13, 1 (2016), 154–167. doi:10.1109/tnsm.2016.2516946 [39] Zhibo Liu, Dongwei Xiao, Zongjie Li, Shuai Wang, and Wei Meng. 2023. Exploring missed optimizations in webassembly optimizers. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 436–448. doi:10.1145/3597926.3598068 [40] Niko Mäkitalo, Victor Bankowski, Paulius Daubaris, Risto Mikkola, Oleg Beletski, and Tommi Mikkonen. 2021. Bringing webassembly up to speed with dynamic linking. In Proceedings of the 36th Annual ACM Symposium on Applied Computing. 1727–1735. doi:10.1145/3412841.3442045 [41] Niko Mäkitalo, Tommi Mikkonen, Cesare Pautasso, Victor Bankowski, Paulius Daubaris, Risto Mikkola, and Oleg Beletski. 2021. WebAssembly modules as lightweight containers for liquid IoT applications. In International Conference on Web Engineering. Springer, 328–336. doi:10.1007/978-3-030-74296-6_25 [42] Scott Malabarba, Raju Pandey, Jeff Gragg, Earl Barr, and J Fritz Barnes. 2000. Runtime support for type-safe dynamic Java classes. In European Conference on Object-Oriented Programming. Springer, 337–361. doi:10.1007/3-540-45102-1_17 [43] Pankaj Mendki. 2020. Evaluating webassembly enabled serverless approach for edge computing. In 2020 IEEE Cloud Summit. IEEE, 161–166. doi:10.1109/ieeecloudsummit48914.2020.00031 [44] Jämes Ménétrey, Marcelo Pasin, Pascal Felber, and Valerio Schiavoni. 2021. Twine: An embedded trusted runtime for webassembly. In 2021 IEEE 37th International Conference on Data Engineering (ICDE). IEEE, 205–216. doi:10.1109/ icde51399.2021.00025 [45] Konrad Moron and Stefan Wallentowitz. 2023. Support for Just-in-Time Compilation of WebAssembly for Embedded Systems. In 2023 12th Mediterranean Conference on Embedded Computing (MECO). IEEE, 1–4. doi:10.1109/meco58584. 2023.10155088

Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Bringing Managed Language Support to WebAssembly with External Library Linking

FSE175:23

[46] Mozilla. 2025. SpiderMonkey. https://spidermonkey.dev/. [47] Otoya Nakakaze, István Koren, Florian Brillowski, and Ralf Klamma. 2022. Retrofitting industrial machines with webassembly on the edge. In International Conference on Web Information Systems Engineering. Springer, 241–256. doi:10.1007/978-3-031-20891-1_18 [48] Shravan Narayan, Craig Disselkoen, Daniel Moghimi, Sunjay Cauligi, Evan Johnson, Zhao Gang, Anjo VahldiekOberwagner, Ravi Sahita, Hovav Shacham, Dean Tullsen, et al. 2021. Swivel: Hardening {WebAssembly} against spectre. In 30th USENIX Security Symposium (USENIX Security 21). 1433–1450. https://www.usenix.org/conference/ usenixsecurity21/presentation/narayan [49] Sam Newman. 2021. Building microservices: designing fine-grained systems. " O’Reilly Media, Inc.". https://www.oreilly. com/library/view/building-microservices-2nd/9781492034018/ [50] Mohammed Nurul-Hoque and Khaled A Harras. 2021. Nomad: Cross-Platform Computational Offloading and Migration in Femtoclouds Using WebAssembly. In 2021 IEEE International Conference on Cloud Engineering (IC2E). IEEE, 168–178. doi:10.1109/ic2e52221.2021.00032 [51] OpenJS. 2025. Express. https://expressjs.com/. [52] Pallets. 2025. Flask. https://flask.palletsprojects.com/en/stable/. [53] Michael P Papazoglou, Paolo Traverso, Schahram Dustdar, and Frank Leymann. 2007. Service-oriented computing: State of the art and research challenges. Computer 40, 11 (2007), 38–45. doi:10.1109/mc.2007.400 [54] Python. 2025. CPython. https://github.com/python/cpython. [55] Python. 2025. jsonschema. https://python-jsonschema.readthedocs.io/en/stable/. [56] Python. 2025. Python-Markdown. https://pypi.org/project/Markdown/. [57] Python. 2025. The Python Performance Benchmark Suite. https://pyperformance.readthedocs.io/index.html. [58] RedMonk. 2022. The RedMonk Programming Language Rankings. https://redmonk.com/sogrady/2022/03/28/languagerankings-1-22/. [59] Micha Reiser and Luc Bläser. 2017. Accelerate JavaScript applications by cross-compiling to WebAssembly. In Proceedings of the 9th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages. 10–17. doi:10.1145/3141871.3141873 [60] Yuxin Ren, Kang Zhou, Jianhai Luan, Yunfeng Ye, Shiyuan Hu, Xu Wu, Wenqin Zheng, Wenfeng Zhang, and Xinwei Hu. 2022. From dynamic loading to extensible transformation: An infrastructure for dynamic library transformation. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). 649–666. https://www.usenix. org/conference/osdi22/presentation/ren [61] Alan Romano, Daniel Lehmann, Michael Pradel, and Weihang Wang. 2022. Wobfuscator: Obfuscating javascript malware via opportunistic translation to webassembly. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 1574–1589. doi:10.1109/sp46214.2022.9833626 [62] Alan Romano and Weihang Wang. 2023. When Function Inlining Meets WebAssembly: Counterintuitive Impacts on Runtime Performance. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 350–362. doi:10.1145/3611643.3616311 [63] Merlijn Sebrechts, Tim Ramlot, Sander Borny, Tom Goethals, Bruno Volckaert, and Filip De Turck. 2022. Adapting Kubernetes controllers to the edge: on-demand control planes using Wasm and WASI. In 2022 IEEE 11th International Conference on Cloud Networking (CloudNet). IEEE, 195–202. doi:10.1109/cloudnet55617.2022.9978884 [64] Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, and Dan Boneh. 2004. On the effectiveness of address-space randomization. In Proceedings of the 11th ACM Conference on Computer and Communications Security. 298–307. doi:10.1145/1030083.1030124 [65] Simon Shillaker and Peter Pietzuch. 2020. Faasm: Lightweight isolation for efficient stateful serverless computing. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). 419–433. https://www.usenix.org/conference/atc20/ presentation/shillaker [66] Shopify. 2023. Bringing JavaScript to WebAssembly for Shopify Functions. https://shopify.engineering/javascript-inwebassembly-for-shopify-functions. [67] Mark Slee, Aditya Agarwal, and Marc Kwiatkowski. 2007. Thrift: Scalable cross-language services implementation. Facebook white paper 5, 8 (2007), 127. https://thrift.apache.org/static/files/thrift-20070401.pdf [68] Spring. 2025. Spring Boot. https://spring.io/projects/spring-boot. [69] Second State. 2025. WasmEdge-QuickJS. https://github.com/second-state/wasmedge-quickjs. [70] Thomas Steiner. 2024. Toward Making Opaque Web Content More Accessible: Accessibility From Adobe Flash to CanvasRendered Apps. In Companion Proceedings of the ACM Web Conference 2024. 1111–1114. doi:10.1145/3589335.3651999 [71] Quentin Stiévenart, David W Binkley, and Coen De Roover. 2022. Static stack-preserving intra-procedural slicing of webassembly binaries. In Proceedings of the 44th International Conference on Software Engineering (ICSE). 2031–2042. doi:10.1145/3510003.3510070

Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

FSE175:24

Shuyao Jiang, Ruiying Zeng, Yangfan Zhou, and Michael R. Lyu

[72] Ben L Titzer. 2022. A fast in-place interpreter for WebAssembly. Proceedings of the ACM on Programming Languages 6, OOPSLA2 (2022), 646–672. doi:10.1145/3563311 [73] Unity. 2025. Unity. https://unity.com/. [74] Luke Wagner. 2017. A WebAssembly milestone: Experimental support in multiple browsers. Mozilla Hacks (14 March 2016). (2017). https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ [75] Dong Wang, Bo Jiang, and WK Chan. 2020. WANA: Symbolic execution of wasm bytecode for cross-platform smart contract vulnerability detection. arXiv preprint arXiv:2007.15510 (2020). doi:10.48550/arXiv.2007.15510 [76] WasmEdge. 2025. WasmEdge. https://github.com/WasmEdge/WasmEdge. [77] WasmEdge. 2025. WasmEdge HTTP Services. https://wasmedge.org/docs/category/http-services. [78] Wasmer. 2025. Wasmer. https://github.com/wasmerio/wasmer. [79] Elliott Wen and Jens Dietrich. 2023. Wasmslim: Optimizing webassembly binary distribution via automatic module splitting. In 2023 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 673–677. doi:10.1109/saner56733.2023.00069 [80] Alon Zakai. 2011. Emscripten: an LLVM-to-JavaScript compiler. In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion. 301–312. doi:10.1145/ 2048147.2048224 [81] Koen Zandberg and Emmanuel Baccelli. 2021. Femto-containers: Devops on microcontrollers with lightweight virtualization & isolation for iot software modules. arXiv preprint arXiv:2106.12553 (2021). doi:10.48550/arXiv.2106.12553 [82] Ruiying Zeng, Shuyao Jiang, Wenxuan Zhao, and Yangfan Zhou. 2026. Debugging Performance Issues in WebAssembly Runtimes via Mutation-based Inference. In Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE). doi:10.48550/arXiv.2604.13693 [83] Yixuan Zhang, Mugeng Liu, Haoyu Wang, Yun Ma, Gang Huang, and Xuanzhe Liu. 2024. Research on WebAssembly Runtimes: A Survey. ACM Transactions on Software Engineering and Methodology (2024). doi:10.1145/3714465 [84] Yixuan Zhang, Shuyu Zheng, Haoyu Wang, Lei Wu, Gang Huang, and Xuanzhe Liu. 2024. VM Matters: A Comparison of WASM VMs and EVMs in the Performance of Blockchain Smart Contracts. ACM Transactions on Modeling and Performance Evaluation of Computing Systems 9, 2 (2024), 1–24. doi:10.1145/3641103

Received 2025-09-11; accepted 2026-03-24

Proc. ACM Softw. Eng., Vol. 3, No. FSE, Article FSE175. Publication date: July 2026.

Related documents

• Experimental Settings in LLM-Based Program Repair: A Study of Inputs, Tool Access, Feedback, and Validation#965480
• A11yLTLNav: Automatic Detection of Accessibility Navigation Failures#965481
• Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations#965482
• A Large-Scale Empirical Study of Quality Assurance Practices and Gaps in AI Agents#965483
• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#965484