The main driver for this release was making WebAssembly GC backend on par with JavaScript backend. Now, only one feature of the JavaScript backend is not supported in Wasm GC: threading. This will be addressed in future releases.
Here's the list of improvements to the backend:
- Reflection support. It's far from being full, but now all features, supported in JavaScript, are also supported in WebAssembly GC.
- Improved generation of virtual tables. Little optimization techniques were implemented to reduce the size of virtual tables generated for large projects.
- Reduced size of overhead, produced for various types of arrays. Actually, there's no more overhead: all object array types share the same code. This can cause insignificant performance loss in favour of a significantly smaller binary size in large projects.
- JS string builtins proposal is now used when available (for now it's only unsupported in Safari), which significantly improves string interchange between Java and native JS APIs.
Another big change worth mentioning is the refactoring of NIO buffers. It was also driven mostly by the need of JS interop in Wasm GC backend, but as a result, all other backends benefit from this improvement. While previously NIO buffers were backed by arrays, now each backend uses more appropriate implementation. This includes typed arrays in JavaScript BE and direct memory addresses in C and old WebAssembly backends. Also, direct buffers in C are now allocated using malloc and using dedicated allocator in Wasm GC, that uses Wasm memory.
The latter change allows overcoming one major limitation of WebAssembly GC proposal: the inability to represent WebAssebmly array type as a JavaScript typed array. WebAssembly memory can be represented directly as a JavaScript typed array. So the solution is to allocate direct buffers over WebAssembly memory and then pass NIO buffers directly to JavaScript without any copying. In this regard JSO now allows passing NIO buffers directly to JavaScript. In this case they will be seen as a type array or as an ArrayBufferView respectively.
When this is not an option, though, and JS interop needs to fall back to copying data between arrays, it's now done via WebAssembly memory. Although one extra copy needs to be performed, the overall performance is times better than copying through WebAssebmly/JS barrier.
To make code re-usable between JavaScript and WebAssembly while still benefiting from the ability to pass data without copying, @JSByRef annotation gets optional parameter. "Optional by-ref" means that any backend that supports it (namely, JavaScript) passes data by reference, while others (WebAssembly GC) copies data.
Special thanks to libGDX project and personally to @xpenatan for testing WebAssembly GC backend with their TeaVM backend, which gave the opportunity to find and fix some bugs. Also, thanks to contributors:
Finally, a big thank you to @reportmill and @shannah
for sponsoring the project as well as other sponsors (see full list).
You can join these people and start supporting the project.