WebAssembly (wasm) Target Platform

Extracted from Feature & Objectives.

Overview

See Bug 1506 describing this feature.

Since Java Applets are not more supported within browser or by OpenJDK for years, it may seems feasible to evaluate the WebAssembly target running within e.g. web browser nowadays.

An initial evaluation on small C++ projects using the emscripten front-end for LLVM's clang++ to wasm compiler, which supports many ported system libraries like SDL, OpenGL, .. has been undertaken successfully with variable results.

• gfxbox2 C++/wasm evaluation
• emscripten
• WebAssembly

The wasm target is comparable to Java bytecode but the wasm virtual machine is not as performant, efficient or flexible as actual native code. The lack of hassle free native threads and native high-performance may remind one of the first JVM steps. The wasm code runs within a virtual machine like the JVM and additionally lacks of native binding capabilities.

Some limitations may be overcome, others are likely by design as it usually runs on the same browser virtual machine as the JavaScript companion. Compromises must be made on shared memory and native threads, cached non-local file I/O and socket communication - while other native features will simply never work, e.g. operating system ioctl-calls, etc.

Opening the door for any language to be compiled to a platform independent intermediate representation (IR) like Java’s bytecode suitable for a versatile runtime environment including its virtual machine is surely still desirable.

Initial C++/wasm Evaluation

Our little gfxbox2 games compiled to wasm run about 40-60% slower within a browser than in native code, depending on coding strategy of our graphics (pixelmap vs SDL/OpenGL primitives).

The used emscripten frontend allowed us to use memory-growth, envelop files used in the wasm file, add cheap stack-overflow cockies and nullptr writes and so forth. Utilization of OpenGL ES via SDL2 was a breeze.

The underlying LLVM compiler did an excellent job and overall, the transition was easy and almost involved no code changes but dropping native thread (std::thread) usage.

The overall program structure had to be adapted to align to the single-thread main-loop workflow and specific emscripten-javascript hooks added to allow seamless interaction. All in all, nothing to be too afraid of and depending on the class of applications to be ported to the browser these days, a feasible procedure.

Java Support

Java bytecode compiler to wasm including some runtime envelop

• J2wasm within J2CL emits naïve Wasm using the text format and it relies on Binaryen toolchain to assemble, link, and optimize
  • 2024 Slides
• TeaVM overview
• JWebAssembly doc
• Bytecoder

Further interesting bits & pieces

• JEP 457: Class-File API
• Babylon

GraalVM

GraalVM experimentally hosts wasm only, but is not producing a wasm target for the wasm (browser) runtime.

• GraalVM + wasm
  • with the help of emscripten
  • GraalVM + JNI

Request for enhancement about wasm target in GraalVM.

Java Browser Outlook

So far the only question arises why reinventing the wheel once again? Dropping utilization of a well working JVM for the web had no technical reasoning.

However, in case no suitable wasm target for the Java bytecode and the Java Runtime pieces can be established, one might either want to also look into bringing back the JRE into the browser or painfully drop Java for C++, as the latter is already close to have acceptable (slower and limited) wasm target runtime properties.