WebAssembly (wasm) Target Platform: Difference between revisions
No edit summary |
No edit summary |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Extracted from [[SW Tracking Report Feature Objectives Overview|Feature & Objectives]]. | Extracted from [[SW Tracking Report Feature Objectives Overview|Feature & Objectives]]. | ||
| Line 10: | Line 8: | ||
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. | 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. | ||
* [https://webassembly.org/ WebAssembly] | |||
* [https://emscripten.org/ emscripten] | |||
* [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ gfxbox2 C++/wasm evaluation] | * [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ gfxbox2 C++/wasm evaluation] | ||
* [https:// | * Project [https://jausoft.com/cgit/gamp.git/about/ Gamp] | ||
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. | 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. | ||
| Line 21: | Line 20: | ||
= Initial C++/wasm Evaluation = | = Initial C++/wasm Evaluation = | ||
[https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ Our little gfxbox2 games] compiled to [https://webassembly.org/ wasm] run about | [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ Our little gfxbox2 games] compiled to [https://webassembly.org/ wasm] run about ~50% slower [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/#online-webassembly-examples within a browser] than in native code, depending on coding strategy of our graphics (pixelmap vs SDL/OpenGL primitives). | ||
The used [https://emscripten.org/ 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 used [https://emscripten.org/ 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. | ||
| Line 31: | Line 30: | ||
All in all, nothing to be too afraid of and depending on the class of applications to be ported | 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. | to the browser these days, a feasible procedure. | ||
= Project [https://jausoft.com/cgit/gamp.git/about/ Gamp] = | |||
[https://jausoft.com/cgit/gamp.git/about/ Gamp] stands for Graphics, Audio, Multimedia and Processing, the same way as JogAmp, but natively plus using WebAssembly. | |||
Gamp replicates JogAmp's experience natively via C++ in a condensed form, allowing a similar workflow on native targets and [https://jausoft.com/cgit/gamp.git/about/#online-webassembly-examples within the browser] via WebAssembly. Ironically this will bring back runs everywhere including the web. | |||
Initial goal reimplementing [https://jausoft.com/blog/tag/graph_type_rendering/ Resolution independent NURBS curves rendering using programmable graphics pipeline (Graph)] has been completed. | |||
Gamp uses [https://jausoft.com/cgit/jaulib.git/about/ jaulib] for general purpose functionality including linear algebra and geometry and builds upon initial wasm experience collected with [https://jausoft.com/cgit/cs_class/gfxbox2.git/about/ gfxbox2]. | |||
= Java Support = | = Java Support = | ||
Java bytecode compiler to wasm including some ''runtime envelop'' | Java bytecode compiler to wasm including some ''runtime envelop'' | ||
* [https://github.com/google/j2cl/blob/master/docs/getting-started-j2wasm.md J2wasm] within [https://github.com/google/j2cl J2CL] emits naïve Wasm using the text format and it relies on Binaryen toolchain to assemble, link, and optimize | |||
** [https://www.wingolog.org/pub/epfl-wasm-gc-feb-2024-slides.pdf 2024 Slides] | |||
* [https://github.com/konsoletyper/teavm TeaVM] [https://teavm.org/docs/intro/overview.html overview] | * [https://github.com/konsoletyper/teavm TeaVM] [https://teavm.org/docs/intro/overview.html overview] | ||
* [https://github.com/i-net-software/JWebAssembly JWebAssembly] [https://github.com/i-net-software/JWebAssembly/wiki doc] | * [https://github.com/i-net-software/JWebAssembly JWebAssembly] [https://github.com/i-net-software/JWebAssembly/wiki doc] | ||
| Line 39: | Line 49: | ||
Further interesting bits & pieces | Further interesting bits & pieces | ||
* [https://openjdk.org/jeps/457 JEP 457: Class-File API ] | |||
* [https://openjdk.org/projects/babylon/articles/linq Babylon] | |||
== GraalVM == | |||
GraalVM experimentally hosts wasm only, | GraalVM experimentally hosts wasm only, | ||
but is not producing a wasm target for the wasm (browser) runtime. | but is not producing a wasm target for the wasm (browser) runtime. | ||
* [https://www.graalvm.org/latest/reference-manual/wasm/ GraalVM + wasm] | * [https://www.graalvm.org/latest/reference-manual/wasm/ GraalVM + wasm] | ||
** with the help of emscripten | ** with the help of emscripten | ||
** [https://www.graalvm.org/22.0/reference-manual/native-image/JNI/ GraalVM + JNI] | ** [https://www.graalvm.org/22.0/reference-manual/native-image/JNI/ GraalVM + JNI] | ||
[https://github.com/oracle/graal/issues/3391 Request for enhancement about wasm target in GraalVM]. | |||
= Java Browser Outlook = | = Java Browser Outlook = | ||
Latest revision as of 22:50, 27 May 2025
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.
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 ~50% 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.
Project Gamp
Gamp stands for Graphics, Audio, Multimedia and Processing, the same way as JogAmp, but natively plus using WebAssembly.
Gamp replicates JogAmp's experience natively via C++ in a condensed form, allowing a similar workflow on native targets and within the browser via WebAssembly. Ironically this will bring back runs everywhere including the web.
Initial goal reimplementing Resolution independent NURBS curves rendering using programmable graphics pipeline (Graph) has been completed.
Gamp uses jaulib for general purpose functionality including linear algebra and geometry and builds upon initial wasm experience collected with gfxbox2.
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
- TeaVM overview
- JWebAssembly doc
- Bytecoder
Further interesting bits & pieces
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.