{"id":3611,"date":"2022-12-23T01:01:00","date_gmt":"2022-12-23T01:01:00","guid":{"rendered":"https:\/\/www.javaadvent.com\/?p=3611"},"modified":"2023-01-11T16:19:04","modified_gmt":"2023-01-11T16:19:04","slug":"webassembly-for-the-java-geek","status":"publish","type":"post","link":"https:\/\/www.javaadvent.com\/2022\/12\/webassembly-for-the-java-geek.html","title":{"rendered":"WebAssembly for the Java Geek"},"content":{"rendered":"

When many Java developers hear the word WebAssembly, the first thing they think is \u201cbrowser technology\u201d. The second thing: \u201cit\u2019s the JVM all over again\u201d. After all, for a Java developer, in-browser apps are prehistory<\/strong>.<\/p>\n

<\/div>\n

In the last few weeks, there have been quite a few announcements around WebAssembly, such as the Docker+Wasm Technical Preview<\/a>. As a Java geek myself, I think we should not dismiss this technology as just a fad.<\/p>\n

Indeed, WebAssembly is<\/em><\/strong> \u201ca bytecode for the Web\u201d (I mean, that\u2019s the name after all), but the similarities between Java and Wasm<\/strong> (lower-cased: it\u2019s a contraction, not an acronym!) really end here.<\/p>\n

If you want to know more about how we came to define the WebAssembly standard, you can learn more about its history on my own blog<\/a>. In the following, I will try to argue that there is more to WebAssembly than \u201cjust the web\u201d.<\/strong><\/p>\n

First of all, a WebAssembly runtime is only shallowly similar to a JVM. For instance, WebAssembly was always meant to be a proper compilation target<\/em> for different programming languages, while the JVM was not, at least, not originally.<\/p>\n

Myth #1: The JVM Is A Polyglot Compilation Target<\/h2>\n

Of course, everyone knows the JVM is one of richest, interoperable language ecosystems there is. We don\u2019t have just Java, we also have Scala, Jython, JRuby, Clojure, Groovy, Kotlin and many many others.<\/p>\n

<\/p>\n

However, the sad, sad reality is that Java bytecode was never really meant to be a general-purpose compilation target<\/strong>. In fact, you can even find literary references<\/a> that spell that out clearly; in \u201cBytecodes meet combinators: invokedynamic<\/code> \u00a0on the JVM\u201d, John Rose<\/a> writes (bold mine):<\/p>\n

The Java Virtual Machine (JVM) has been widely adopted in part because of its classfile format, which is portable, compact, modular, verifiable, and reasonably easy to work with. However, it was designed for just one language\u2014Java\u2014<\/strong> and so when it is used to express programs in other source languages, there are often \u201cpain points\u201d which retard both development and execution.<\/p><\/blockquote>\n

The paper describes how and why the invokedynamic<\/code> opcode was introduced in the JVM; in fact, it was specifically introduced to support dynamic languages targeting the JVM as a runtime. At the time, those were many: JRuby, Jython, Groovy, etc\u2026 This opcode was not added because<\/em> the JVM was supposed<\/em> to support such languages; but because people were doing it anyway: so, it was better just to acknowledge it!<\/p>\n

In other words, the JVM, as it was at the time, was not<\/em> an adequate compilation target for dynamic languages. We may even argue that the JVM became a compiler target not because it was the best<\/strong> compilation target, but because people wanted to interoperate with it because of adoption and support \u2026just like JavaScript!<\/p>\n

GraalVM: One VM to Rule Them All<\/h2>\n

The GraalVM<\/a> project has recently gone mainstream. This project includes a Just-in-Time compiler targeting regular Java bytecode, an API to build efficient language interpreters, and, recently, a native image compiler.<\/p>\n

One of the original goals for GraalVM was to be \u201cOne VM to rule them all\u201d<\/a>, i.e. to be a polyglot runtime<\/em>.<\/p>\n

But Truffle does not define a polyglot compilation target<\/em>. Instead, the Truffle API allows you to build<\/em> an efficient, JITting interpreter<\/strong> for dynamic programming languages<\/em> using a very high-level representation (an AST-based interpreter, if you are interested).<\/p>\n

\n

Note for the nitpicker. <\/strong>Now, once you enter the programming-language-rabbit-hole everything gets kind of \u201cmeta\u201d. Indeed, with Truffle you can write a JITting interpreter for some other \u201cproper\u201d bytecode format.<\/p>\n

In fact, there is a Truffle-based interpreter for LLVM (Sulong); and, sure, LLVM bitcode is meant<\/em> to be a multi-platform\/multi-target compilation target. So, by the transitive property, you may argue that GraalVM\/Truffle do support a multi-platform compilation target.<\/p>\n

This is technically correct (which is the best<\/em> kind of correct<\/a>), but there are many considerations to be made, and there is not enough space here to discuss them all. In short, LLVM bitcode is meant to be a compilation target, but it was not necessarily meant to be a cross-platform runtime language<\/em> (e.g., there are slight variations in the instructions you may have to use, depending on the CPU\/OS you want to target). Moreover, as opposed to WebAssembly, which is a multi-vendor standard, GraalVM and Truffle are, to this day, open source, community-driven, but single-implementation efforts (work has recently started to bring it to the OpenJDK and possibly to the Java Language Specification<\/a>).<\/p>\n

Ultimately, WebAssembly is also another language that GraalVM\/Truffle is able to support, so if you want to use GraalVM, you might even target Wasm!<\/p>\n<\/div>\n

Myth #2: It\u2019s Just Another Stack-based Language VM<\/h2>\n

WebAssembly is defined as a virtual instruction set architecture (ISA) for a structured<\/em> stack-based virtual machine<\/a>.<\/p>\n

The word structured<\/em> here is key, because it is a very significant departure from the way, say, the JVM works. In practice, in a structured stack machine most computations use a stack of values, but control flow is expressed in structured constructs such as blocks, ifs, and loops. Moreover, in the WebAssembly language, some instructions can be represented both as \u201csimple\u201d and as \u201cnested\u201d.<\/p>\n

Let\u2019s see an example. In the stack-based Wasm machine the expression:<\/p>\n

( x + 2 ) * 3<\/pre>\n
\n
 int exp(int);\n    Code:\n       0: iload_1\n       1: iconst_2\n       2: iadd\n       3: iconst_3\n       4: imul\n       5: ireturn<\/pre>\n<\/div>\n
Could be translated in the following sequence of instructions:<\/p>\n
\n
(local.get $x) \n(i32.const 2) \ni32.add \n(i32.const 3) \ni32.mul<\/pre>\n<\/div>\n