graal
graal copied to clipboard
oracle
Wasm target architecture for native image
Feature request
Is your feature request related to a problem? Please describe. I'm trying to port closure compiler to wasm so that it can run from within a browser.
Describe the solution you'd like. Closure compiler already has build support for native image. So I was hoping to be able to use the LLVM backend but it seems like adding a new target architecture is a lot more work than I had expected.
Describe who do you think will benefit the most. Anyone using GraalVM to build native image versions of their app would benefit from this, as they can now port their application to the web easily. Java developers who want to write a new application from the web could also benefit from this, they can now start developing in a language that they are already familiar with.
Describe alternatives you've considered. I have tried the following alternatives:
- CheerjP, works and runs closure compiler in a browser successfully, but the runtime is rather bulky, which needs to be downloaded first before you can run jar files. I'm also not sure about the performance. Wasm could be faster. Though I don't have any evidence to back this up.
- TeaVM, could work as well. Though I haven't tried this yet to be honest. Their docs seem a bit daunting.
- JWebAssembly might work but it is currently not production ready and still missing some crucial features.
- Bytecoder doesn't seem to work for my use case since it doesn't support reflection. Something that closure compiler depends on.
Additional context. The links in LLVM Backend for Native Image seem useful for implementing a new target.
Express whether you'd like to help contributing this feature I'd love to, though if this feature request requires a similar change to the changes in [AArch64][Statepoints] Statepoint support for AArch64., I don't think I'm the suitable person to do this. I was hoping it would only require a few flags to be set on llvm but it seems like that's not the case.
@jespertheend thanks for the feature request, we are constantly adding new support to native-image and if we find it valuable to the community then surely we will add it in our future releases.
We have thought about a WASM backend, but it is not on our list of features to implement in the near future. One of the biggest problems is the missing GC support in WASM: neither the GC of the underlying WASM/JS VM is exposed, nor stack walking is possible to include the existing SVM GC.
Ah yeah makes sense. Thanks for the info! Would the wasm gc proposal make this any easier?
Would the wasm gc proposal make this any easier?
Yes, once WASM has a proper GC interface things are getting much more feasible.
Hi, now that there's an experimental WASI SDK for .net, can't such techniques be used to work around current Wasm limitations to run Substrate VM on Wasm?
Ref: https://www.fermyon.com/blog/dotnet-wasi
https://github.com/SteveSandersonMS/dotnet-wasi-sdk
https://www.youtube.com/watch?v=A0vz_BWxIMc
Don't seem to be the only one wanting to port closure compiler to wasm 😉 subscribing to this issue.
ping me @jespertheend if you ever release a wasm version of closure compiler :)
@jimmywarting I'm actually about to ditch closure compiler in favour of terser to be honest. From my limited testing, builds seem to be slightly larger, but that seems worth it considering that it can run in a browser and generally seems to have less complexity. You might have some luck with https://github.com/mirkosertic/Bytecoder but some features seem to still be missing for it to successfully build closure compiler to wasm.
@christianwimmer Potentially interesting related links:
- .Net notes about why they can't leverage GC proposal yet
- LLVM and clang progresses on GC proposal support
- Draft WASI support in TeaVM
- J2CL which currently provide the most advanced Java to Wasm support (and leverages the GC proposal)
Hi!
Author of https://github.com/mirkosertic/Bytecoder here. I can confirm that native garbage collection support is an issue in WebAssembly. The current Wasm GC proposal is in "proposed" status, as seen here: https://chromestatus.com/feature/6062715726462976. However, Google's J2CL Wasm backend seems to rely on this proposal, so I am really not sure when we can expect the final release and support in Chromium at least. Till this point, every Wasm backend for JVM bytecode needs to provide its own implementation for garbage collection. And implementing a fast and reliable garbage collector can be really tricky, and it can become a nightmare and impossible if you want to prevent stop-the-world during GC runs in a Wasm in a single threaded environment. Maybe we can get around that with reference counting, but performance is a very important part of it. Good escape analysis will remove some of the heap allocations, but in most real life applications a lot of stack allocation will remain.
But when the time comes and the Wasm GC proposal is final, it would be good to know what might be a feasible way to use the Graal native image compiler with Wasm. The LLVM backend path might work, but it is for sure not the fastest way. So what I am searching is a kind of documentation about how to provide a custom backend to Graal, or a kind of "embedded" API to run Graal, retrieve the IR (Graphs) and use them for a custom backend for code generation. Something that can be completely based on JVM, without further toolchains like LLVM and co.
GC proposal made a lot of progresses in 2022 and moved to phase 3. We can't be sure when it will move to phase 4 but could be possible in 2023.
Implementations in other browsers has started:
Hello, I'm writing an article for InfoWorld about Java and WASM. native-image --features=wasm sure would be nice. Could anyone comment on the status or any thoughts?
There has been quite a lot of movement around the WASM GC implementation, and it is available by default on chrome now, see https://developer.chrome.com/blog/wasmgc/
It might make sense to re-alive this issue.
Why a Java AOT solution has to rely on the GC implementation of WASM? A Java GC should be runnable on WASM with low level memory management API, and on the other side using WASM's GC will most likely lose the GC related APIs on Java side.
@Martin1994 From the article:
The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K!
Compare it to the size of a C# application compiled to WASM, which is on the MB range, due to in part to having to also download on every site a complete GC/runtime implementation.
Given that Java can already be compiled to WASM (closure compiler, teawm), I believe that the WASM GC proposal’s API is more than fit for Java’s use case, and there are many advantages to using Graal, like polyglottism, size reduction (due to the closed world assumption, it can remove a bunch of classes that are never accessed), etc.
In any case, this issue deserves a fresh look, because it opens GVM binaries up to new deployment targets, regardless of GC
(Consider users of --gc=epsilon, for example)
GC being shipped in several popular engines is a signal that WASM in general is maturing and stabilizing.
FYI, Firefox 120 now enables Wasm GC by default (it was hidden under a flag for quite some time). I'd say the browser side is quite ready now. Kotlin team has been demoing/optimizing their work on Wasm GC since march, it'd be great if Graal supports it also.
https://www.mozilla.org/en-US/firefox/120.0/releasenotes/ https://twitter.com/bashorov/status/1716891482487988630
WASM GC is available in V8 (Chrome, Deno and soon Node). It'd be very disappointing to not see it rapidly coming to GraalVM
We are working on and have an in-progress implementation that outputs Wasm (with the WasmGC spec).
It would be really helpful for us if people could explain their use-cases for having a WasmGC backend. What sort of deployments scenarios do you foresee or have need for (e.g. do you need to target browser applications, or run Wasm modules in standalone mode with WASI)?
Thank you!
It would be really helpful for us if people could explain their use-cases for having a WasmGC backend. What sort of deployments scenarios do you foresee or have need for (e.g. do you need to target browser applications, or run Wasm modules in standalone mode with WASI)?
Primarily browser apps (to share the code between frontend and backend and to leverage the existing Java skills).
Hello, I am one of the maintainers of the Kotlin-Java bindings for the Godot game engine (https://github.com/utopia-rise/godot-kotlin-jvm).
Godot supports exports for the main 3 desktop OS, Android, iOS and wasm. Wasm is currently the only export we don't support because we lack a simple way to run a JRE inside the browser. We already support the use of native images (our only way to run it on iOS currently) and a wasm target would be welcomed to complete our Godot support.
An alternative would be to use Kotlin/Native and Kotlin/Wasm instead of native images, but Godot being a C++ engine, we rely heavily on interop. Using different backends for Kotlin would require us to implement a specific interop layer for each of them. It would be much simpler for us if we could just keep using a regular JRE + JNI context for all of them.
I am one of the developers of the Eclipse Epsilon project. We provide a family of mini-languages for managing object-oriented system models (e.g. validating them, generating code from them, and so on). They are all interpreted languages, running on top of Java.
We started as being Eclipse-centric (it was the shiny new thing back in the mid 00s), but we are seeing more and more people interested in doing modelling from their browsers (e.g. from low-code development platforms). In fact, to make it easier for people to try out our languages, we've created a web-based Playground for the Epsilon languages.
The annoying part is that, since we can't run Java code on the browser, executing the code in the Playground involves spinning up a Google Cloud Function that runs the script, which is 1) costly and 2) slow. We'd very much like to use something like the Graal integration in Micronaut to package up our interpreter as a module that we could use from the Playground.
It'd also open other opportunities - for instance, we have the start of a language server for Epsilon, which is also written in Java. With a WasmGC export, we could look into running the language server from Node.js, which is one of the default runtimes supported by VS Code.
The annoying part is that, since we can't run Java code on the browser, executing the code in the Playground involves spinning up a Google Cloud Function that runs the script, which is 1) costly and 2) slow. We'd very much like to use something like the Graal integration in Micronaut to package up our interpreter as a module that we could use from the Playground
https://github.com/tlaplus/tlaplus has a pretty similar use case.
It would be really helpful for us if people could explain their use-cases for having a WasmGC backend.
Running Java code in browser environments would be our primary target, but WASI (although still in its infancy) should be ignored too. However, important feature in both cases would be as-good-as-possible support for integrations with JavaScript (in browser) and other WASM modules (especially ones written in languages other than Java).
Everything that has to do with compiling low-dependency Scala 3 programs to WASM, basically. It needs GC support for that.
On Wed, 8 May 2024, 10:10 Gordan Krešić @.***> wrote:
It would be really helpful for us if people could explain their use-cases for having a WasmGC backend.
Running Java code in browser environments would be our primary target, but WASI (although still in its infancy) should be ignored too. However, important feature in both cases would be as-good-as-possible support for integrations with JavaScript (in browser) and other WASM modules (especially ones written in languages other than Java).
— Reply to this email directly, view it on GitHub https://github.com/oracle/graal/issues/3391#issuecomment-2099998795, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHP224OX3SZ4NG7I4XEQCDZBHMWJAVCNFSM437LSQD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBZHE4TSOBXHE2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
