On Wed, Sep 18, 2024, 5:16 a.m. Adam Zielinski < adam.zielin...@automattic.com> wrote:
> On Wed, Sep 18, 2024 at 2:39 AM Hammed Ajao <hamieg...@gmail.com> wrote: > > > Running Wasm and PHP virtual machines together presents several > significant challenges and potential issues: > > • Memory Management and Isolation: Each VM has its own memory model and > garbage collection strategy. Data passing between VMs often requires > expensive memory copying. Coordinating garbage collection can lead to > memory leaks or crashes if not handled properly. > > • Performance Impacts: Context switching between VMs introduces > overhead, especially with frequent interactions. Interoperability can > create latency due to data serialization and deserialization. > Synchronization issues may arise when one VM needs to wait for the other. > > • Security Concerns: Discrepancies between PHP's more permissive > environment and Wasm's stricter sandboxing can create vulnerabilities. The > communication layer between VMs could be exploited for cross-VM attacks if > not properly secured. > > • Debugging Complexities: Developers must use separate debugging tools > for each VM. Stack traces spanning two execution contexts can be confusing > and hard to interpret. > > • Compatibility and Maintenance: Independent evolution of PHP and Wasm > VMs may introduce breaking changes, requiring constant updates to the > integration layer. API changes in either environment necessitate > adjustments in the integration code. > > • Resource Consumption: Running two VMs simultaneously increases CPU and > memory usage. Longer initialization times may impact applications requiring > quick boot times. > > • API and Communication Design: Designing efficient and secure APIs for > inter-VM communication is critical but challenging. Marshaling data between > PHP and Wasm adds complexity, especially when different programming > languages are involved. > > > > While these are definitely challenges, aren't they largely the same > for most languages intending to support WebAssembly? > > – Adam > Yes and no. The primary goal of WebAssembly is to support high-performance applications on web pages. The premise is simple: JavaScript is the only language natively supported by browsers, but developers want to use various other languages (e.g., C, C++, Rust), particularly for performance-critical tasks. WebAssembly allows code written in these languages to be compiled to a universal format (Wasm) that browsers can run efficiently. However, in the case of PHP, many of the benefits that WebAssembly brings to other languages are already available through PHP extensions or FFI for non-performance-sensitive tasks. Integrating a Wasm runtime into PHP would be a complex undertaking with significant risks, but it wouldn't necessarily provide proportionate rewards, which is the main point I'm trying to make. Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility. This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case). In essence, WebAssembly is great for certain scenarios, but PHP has existing mechanisms that make the addition of a Wasm runtime potentially redundant for most use cases. Best, Hammed >
