New WebAssembly backend

[konsoletyper]

Hi, I'm glad to announce that I just published preview of new WebAssembly GC backend.

Let me dig dive in history a little bit. First WebAssembly backend was ready somewhere around 2016/2017, when WebAssembly MVP spec was in development and browsers still had bugs in Wasm support and could not even print disassembly. This old backend works perfectly, but I never had enough motivation to publish some docs and encourage community to switch to WebAssembly. The main reason was the inability to create seamless interoperation layer between Java and JS objects.

This is caused by the fact that WebAssembly does not (or at least did not) operate in terms of objects, but rather has a large flat piece of memory called "heap". TeaVM Wasm BE has its own allocator and its own tracing GC implementation, whereas JS lives with its own GC. And it's the fact: one can't just make two different managed heaps each with own GC to communicate to each other. Or at least, communicate seamlessly. This means, that from both sides objects needed to be explicitly "acquired" and "released", which would lead to some sort or reference counting, even when one want to pass callback to JS API.

Another issue was the size of generated binary and its performance. Performance is better than that of JavaScript, but not significantly better. But the generated binary is huge, usually 5x times larger than JS generated from the same source. On one hand, this could be optimized by shrinking data section, which had just unpacked representation of Java class metadata, by providing some sort of compression. On the other hand, I could do nothing with code section.

Why did these issues occur? Because of GC! No, GC itself is tiny, about 10K, but the problem with WebAssembly is that it does not allow to access CPU stack. Usually, managed runtimes access stack directly when they perform mark phase of GC, but in the absence of access to the stack the only viable alternative is maintaining shadow stack, which in turn has tremendous overhead, both size- and performance-wise.

WebAssembly GC proposal adds objects (or structures in its terms) to WebAssembly, so it becomes possible to make references between JS and WebAssembly objects, which effectively allows to re-create JSO, Java-to-JavaScript interaction layer. This in turn allows to take existing programs and almost without modifications compile them with new backend. Chrome and Firefox added support for this proposal almost a year ago, Safari provides it as technology preview.

I spent several months implementing support for WebAssembly GC. This is not just "small extension", this proposal is a game changer that requires to re-think and re-write entire backend, which I did. Instead of modifying existing WebAssembly BE, I just created a new one, so both co-exist together. My experiments have shown that with Wasm GC performance is a bit better than with Wasm MVP and much better than with JS (although still far from near native speed), while binary size is comparable to JS. Given this, and given that WebAssembly has native int64 support (which allows fast long implementation) and float32 (which allows to avoid some rare issues with rounding in case of using float), I'm determined to push new Wasm GC BE to release stage and to encourage community to switch to it.

As for now, Wasm GC BE supports almost everything the JS BE does, except for:

• "Advanced" reflection, i.e. traversing annotations, traversing and calling methods and fields of classes, getting class by name
• Support for @Async annotation, which means not only support of this annotation in user code, but also those methods in TeaVM classlib that utilize @Async internally, like Thread.sleep, Object.wait, etc.
• IDE support
• Development server
• Passing arrays to and from JS by reference. Note that this isn't just "unimplemented" feature, but the thing that impossible to implement even in theory, unless WebAssembly adds ability to represent Wasm GC arrays as JS ArrayBuffer. I'm planning to introduce extension to JSO to pass NIO buffers between JS and Java, which would allow to distinguish same semantics.
• Full ESM support, since as of now browsers don't integrate WebAssembly modules in ES module system, but wrappers can be written manually and eventually TeaVM could generate such wrappers.

To try WebAssembly GC in action, you can open old good sample. Unfortunately, I still did not have a chance to run WebAssembly GC with something really big, only some small examples like this.

If you want to try WebAssembly GC as a developer, you better ask me directly or learn code, there's still no documentation at all. As a quick start with gradle, learn this sample. In short, everything related to Wasm GC is located in teavm.wasmGC DSL. And don't forget that new backend is only available in latest preview build.

To start with Maven, you need to set tagetType property of your plugin execution to WEBASSEMBLY_GC. Additionally, you need to configure copying of WasmGC runtime:

          <execution>
            <id>please-specify-some-appropriate-id</id>
            <goals>
              <goal>copy-webassembly-gc-runtime</goal>
            </goals>
            <configuration>
              <targetDirectory>${project.build.directory}/directory/to/copy/runtime/to</targetDirectory>
            </configuration>
          </execution>

From HTML side you need something like this:

<!DOCTYPE html>
<html>
<head>
    <title>Main page</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
    <script type="text/javascript" charset="utf-8" src="path/to/fileName.wasm-runtime.js"></script>
</head>
<body>
    <script>
        async function main() {
            let teavm = await TeaVM.wasmGC.load("path/to/fileName.wasm");
            teavm.exports.main([]);
        }
        main();
    </script>
</body>
</html>

During next few months I'm going to prepare backend for release, which does not mean that I'm going to implement missing features, but rather fix bugs and write some documentation. I hope for your feedback and good luck with trying TeaVM.

[Ihromant]

Magnificent job, Alexey!

I can try my pet project with WASM GC. It has 40k lines of code, interoperates with DOM. It matches your description (I assume that I'm using nothing you mentioned in "except"). Project currently compiles with maven. Probably there should be some kind of FAQ or thread for people who are trying WASM GC and facing unknown issues.

[Ihromant]

@konsoletyper It's WIP, i'm constantly developing it and adding new functionality. Readiness is approx 60-70% (at least I hope, I already did 2 wrong estimations :) ). This is (probably) expected, so thanks for your assistance. Will check.

[Ihromant]

Wow, now I can confirm that it works as expected. This is my confirmation. Now waiting for @xpenatan

[xpenatan]

The extend JSObject is fixed here but Im having another issue related to a hack I did that worked for javascript and does not with webassembly hehe 😆. I guess @konsoletyper can give me some tips.

Libgdx desktop GL classese use Buffer, IntBuffer, FloatBuffer and some more to call GL commands. The problem is that webgl uses Float32Array, Int32Array, Int8Array for GL calls. The early days with gdx-backend I was just copying every byte and creating a new typed array every frame which is a big performance hit.

Few months ago I did some hacks to improve performance in Javascript side to obtain the typedarray data from teavm "T" class like TShortBufferOverArray, TIntBufferOverArray, TFloatBufferOverByteBuffer and perfornace was improved. Is there a way to obtain typed arrays from java buffers ?

[konsoletyper]

@xpenatan on JS side you don't need any hacks with T classes. You can just use existing Java API and call array method on buffers. Then you can define native method that takes Java array by reference and returns corresponding JS TypedArray. Perhaps, I should have just included these converters right into TypedArray wrappers in JSO out-of-the box.

As for Wasm GC side, please, read my post. I mentioned this: Wasm GC arrays aren't available as JS ArrayBuffer. So there's no way to use @JSByRef in Wasm GC. I'm going to slightly different thing: implement Java NIO buffers over Wasm heap (which is available as ArrayBuffer) and this will make it possible to pass direct NIO buffers to/from JS side without copying. But this will be later. Anyway, I would appreciate if you made some experiments, even at cost of performance loss on copying data to WebGL. If you make it right now, it will make life easier for you and me when I finally implement buffers.

[xpenatan]

There are some cases that libgdx creates a TIntBufferOverByteBuffer object instance (TIntBufferOverByteBufferBigEndian or TIntBufferOverByteBufferLittleEndian, dont remember now) somewhere in their code and was not possible to obtain the javascript array because the getArray throws an exception. The hack I did was to read byteByffer internally and obtain the int8Array. Having a helper to obtain int8Array will help a lot.

[xpenatan]

• Libgdx tests:

[xpenatan]

@xpenatan well done! Sorry for a bit weird error reporting, it should have be more user-friendly like "@JSByRef not supported by WebAssembly GC", but this is preview. As for investigation methods, you can use disassembler here: https://teavm.org/tools/wasm/disasm/. To make life easier, enable generation of name section in wasm file (it's the same option that controls minification of JS) and debug information (it should be embedded in wasm file, see TeaVMTool.setWasmDebugInfoLocation). In this case you'll get disassembly with all symbol names and comments referring to original source location (including inlining info).

Thanks. The console error was not helping on which GL calls was the issue. The disarm helped 👍

[konsoletyper]

@xpenatan see the address on first screenshot in the very end of error? It's address in decimal. Convert in to hex and search is disassembly. You'll get exact instruction

[xpenatan]

Pushing teavm to its limits with Metaprograming hacks and some others I got GLTF to work.

I will wait for proper reflection support and Wasm heap as ArrayBuffer mechanism. Libgdx use Threads so I had to comment out some internal classes.

[konsoletyper]

@xpenatan great, here are my thoughts

1. LibGDX works with GWT, right? So there's at least some core subset which works without threads. I recommend to avoid using threads and @Async when possible, since it's performance killer. Moreover, it's unpredictable performance killer, which means that it does not affect performance of code that actually uses it, but of some code that you think is completely irrelevant.

2. As for ArrayBuffer, sure, I understand you. On the other hand, typical game should avoid uploading textures/meshes to GPU when possible and do this only when game/level loaded. Considering that Wasm could improve performance in other places (like game logic, physics, AI), somewhat slower loading could be reasonable trade off.

3. GWT lacks reflection, right? But it still works with libGDX. You can wait until I implement reflection (this would take several months or even a year), or do something with this right now. Why do you need reflection in the first place? IMO, reflection should be avoided when possible. In CoSpaces Edu we don't use reflection. To do JSON serializations and REST API we use Java annotation processors and Kapt/KSP respectively. Rationale: we compile both to Web, Android and iOS, and each platform has its own problems with reflection (on Android r8 needs special annotations, for iOS we use GraalVM, which also requires additional configuration). Also, reflection is a performance killer.

[xpenatan]

1: Yes. It emulates some classes that GWT does not support. I'll take a look at it and do the same for teavm.

2: The whole copying buffer thing I got it wrong. I created a small profile to log all GL commands to see what is going on and buffers are only being used when loading models. The render loop is not passing any buffers to WebGL commands. 🙏

3: Yes, libgdx does by using GWT code generator. I used metaprograming to get the last example working. I'll start testing other demos to see how it goes.

[konsoletyper]

Hey, guys. I fixed several bugs according to feedback and published new preview build. I'm going for vacation, so I'll not be able to fix any further bugs for the next week.

[lax1dude]

Great job! I really appreciate you put in the time to get this all working. Please don’t kill off the legacy WASM backend yet though, my impression of WASM GC right now is that the authors if the WebAssembly spec rushed it, and it’s still less than even an MVP with their stupid arrays that can’t be copied efficiently. I don’t care that the legacy WASM backend makes a larger binary, I was gonna compress it with LZMA anyway which seems to reduce its size by like 75%. Wait until the WASM GC spec itself is actually complete before killing off the legacy WASM backend you spent nearly a decade working on.