Wasm target architecture for native image #3391
Comments
|
@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. |
|
@christianwimmer please advise |
|
We have thought about a WASM backend, but it is not on our list of features to implement in the near future. |
|
Ah yeah makes sense. Thanks for the info! |
Yes, once WASM has a proper GC interface things are getting much more feasible. |
|
Ah cool! I stay on the lookout for that then. Thanks for the info. |
|
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://github.com/SteveSandersonMS/dotnet-wasi-sdk |
|
Don't seem to be the only one wanting to port closure compiler to wasm 😉 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. |
|
@christianwimmer Potentially interesting related links:
|
|
Another tool in this area is bck2brwsr. |
|
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:
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/ |
|
WASM GC is available in V8 (Chrome, Deno and soon Node). |
|
Hello? Where are we on this? |
|
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. Thank you! |
|
@lisonge, you can convert Svg2Vector.java to Kotlin 🫣 and continue using Kotlin Multiplatform 😉 |
@bashor The third-party library |
|
@axel22 our use case is mostly server side, similar to Node. we want to support WASI as a server side target, especially on platforms like Cloudflare Workers. many isolate-based hosting platforms can only accept WASM or JavaScript. compiling to WASM is therefore a fundamental need unless V8 begins accepting other binary types (unlikely). this would also lower the cost floor for hosting a GraalVM application significantly. because WASM is not supported yet, one must resort to a container or a full VM, or even bare metal, all of which have much higher cost floors than isolate-based hosting. |
|
We are working on Java stack for Internet Computer blockchain platform https://internetcomputer.org/. Currently developing Java Agent libraries but there is a demand for Java based backend smart contracts (canisters). Internet Computer backend is based on WASM and currently supports different languages like Rust, C++, Python and Javascript. While IO access will be quite restrictive, we will need to support Java reflections and annotations to be able serialize and deserialize Java types (like Jackson or Gson) to internal ICP data format. We already have code for that. Also support libraries like Bouncy Castle for encryption and decryption. |
|
This is really exciting! We'd love to be able to support a Java PDK for Extism, which would mean supporting a Java library that calls some external functions (some static, like wasip1), and some created by a Host environment, linking them dynamically. Extism environments are embedded within other applications including things that run on the server, browser, IoT, and mobile. |
|
I want to run my own swing application on wasm. |
|
Is there any new regarding this topic? To me it seems all the required infrastructure is there (GC Proposal, Reference Types, Atomics). |
|
Target browser. |
|
My use case is to run the Pkl Truffle language in the browser (for educational purposes). |
|
Very interested in WASI / WIT support to be able have the graal ecosystem target a custom plugin ecosystem. Basically the goal is to allow for third-parties to write a plugin in whatever language they want, so having the graal ecosystem as an option would be a huge win. |
|
@Sintrastes - curious if you've come across https://extism.org, which makes all of that possible today across many more languages than WIT can generate. we don't have support for GraalWasm yet, but would be open to collaborating! we also have a similar binding generator toolchain with support for Go, Rust, TypeScript, Python, C#, C++ and Zig (with more coming!). we release all of this freely and under permissive licenses, learn more here: https://docs.xtp.dylibso.com/docs/concepts/xtp-schema |
|
@nilslice - Interesting! No, I was not familiar with this previously. In terms of the IDL, are there plans to add support for things like sum types, like in WIT? |
|
@Sintrastes - great question, and probably not in the near term, but it's not out of the question. XTP schema takes a very pragmatic approach to try and bring wasm to every app; vs try to make all apps wasm. So we take lots of care to not introduce features that are incompatible or create a non-idiomatic mess of generated code. Sum types could be done, but they don't exist in all the languages we support - so we'd have to hand over a wonky Frankenstein combination of structs/methods/enums/states etc. to our users and we have a hard time shipping things that don't work great. We also stick closely to OpenAPI spec, given that a local in-process plugin is basically just a bi-directional API call, and there's a LOT of OpenAPI based systems out there. I don't mean to take over the discussion here, so please feel free to join us on Discord: https://extism.org/discord |
|
https://github.com/stackblitz/bolt.new has opened a low-code tool for using llm. issue: can Graal introduce more runtime support?, such as GraalPython, GraalJS, Espresso (Java), etc., and convert these runtimes into wasm. My personal experience using graal: And now is the era of AI, and entrepreneurial technology selection is more inclined to languages such as JS and Python. If wasm can be supported, Graal can be more organically combined with AI, and Graal will have a wider range of usage scenarios. |
Graal can get your jvm code to interact with python code and libraries directly. That is not the problem, that topic is not really a factor. A more important entrepreneurial tech is that webassembly is cloud native, you can run it with docker directly. |
|
@Frontrider This only satisfies running Python on the Java backend and running WASM in container runtimes (WasmEdge). It cannot run in browsers. The following is a commercial product that can run Java applications in browsers, including Swing, Applet, and extensive framework support: https://cheerpj.com/ |
|
Cheerpj however is rather slow (while it can run Swing technically, "real" Swing applications work but are no fun to use). Furthermore they have a rather special view on OpenJDKs GPL+linking exception - I once asked for their WASM platform peer bindings (file/network/awt/java2d/etc) and the declined stating GPL+linking covers this. |
|
@ceisserer Thank you for your response. It's possible that CheerpJ does not support WebGPU very well? GraalVM's native-image compiles Java code into native code through the compiler toolchain, and it can also support WASM through the compiler toolchain. I am very hopeful that Java GUI technology can be brought back to the browser through GraalVM. |
This is already proven to be feasible, as this is basically what Kotlin Compose does for the web. Except it uses their own compiler. I'm also reading some articles on SPA-s, and some of the things those are used for are literally better to do even with swing. When you have a lot of data to display, and the dom tree becomes way too convoluted. |
|
Now that Wasm GC has arrived in all major browsers (Chrome, Firefox and even Safari) is there any chance for some fresh wind in this feature request? |
|
Did my wishes finally come true? |
|
Well, it exists now: https://graalvm.github.io/graalvm-demos/native-image/wasm-javac/ But there's still no official announcement of anything |
|
More than one week after WASM I/O now and still no further info? :-( |
and others
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:
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.
The text was updated successfully, but these errors were encountered: