Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Compiling via Emscripten. #336

Closed
kkimdev opened this issue Apr 17, 2018 · 9 comments
Closed

[Feature Request] Compiling via Emscripten. #336

kkimdev opened this issue Apr 17, 2018 · 9 comments
Assignees
Labels

Comments

@kkimdev
Copy link

kkimdev commented Apr 17, 2018

It would be great if we can run graal on web using Emscripten

@thomaswue thomaswue self-assigned this Apr 17, 2018
@davleopo
Copy link
Member

Hi @kkimdev,

We previously implemented a JS back end for Graal and JS specific optimizations that allowed us to AOT compile Java applications (and Truffle language AST interpreters) to the web (see http://doi.acm.org/10.1145/2816707.2816715).
However, there are currently no plans to pursue this effort further.

@kkimdev
Copy link
Author

kkimdev commented Apr 18, 2018

Thanks for the information!

@thomaswue
Copy link
Member

WebAssembly being available could be however be an opportunity to revisit this. We are interested in ideas and thoughts on how this could work in practice (and what limitations would be acceptable). The research paper is a good summary of our experiences when we did early investigations in this direction.

@chicoxyzzy
Copy link

Would be great to have wasm-bindgen-like possibilities in GraalVM
@thomaswue could you please provide a link to that research paper?

@unmellow
Copy link

unmellow commented Feb 27, 2019

one suggestion that might sound Accusatory sorry in advance
why not use WASM in place of LLVM? I've heard that LLVM posses
security threats that WASM doesn't plus you'd get support for go and most
(I'm not sure about plain C) languages you currently support
also i think it was Mozilla that saidone of the reasons they chose to make WASM
because LLVM makes breaking changes at to high speed a rate
to be used as a standard (i know the JVM isn't a standard in the same way as
JavaScript WASM etc is but i think it still applies)

@eliasvasylenko
Copy link

After a bit of a wander through the commit history it looks like there is a new LLVM backend for Graal since this was asked? Which appears to be the simplest route to implementing and maintaining a new JS/WASM backend in the future. https://github.com/oracle/graal/blob/master/substratevm/LLVM-NEW-BACKEND.md

But while an extra layer of indirection via LLVM IR makes for less work here, I'm sure it also inhibits certain optimisations available to the direct-to-javascript approach described in the paper.

@unmellow I may have misunderstood you, but when you talk about e.g. supporting Go I think you're talking about a WASM frontend, whereas this issue is concerned with a JS/WASM backend. That is, "running Graal on WASM" rather than "running WASM on Graal".

@chicoxyzzy I think he was referring to the paper linked by @davleopo.

@unmellow
Copy link

@eliasvasylenko true i do have a (bad) habit of not creating my own issues when i can

@Zireael07
Copy link

Has this really been "completed" (i.e. done)?

@alina-yur
Copy link
Member

Hi @Zireael07. Sorry for miscommunication, this is not planned at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants