Embedding Truffle Languages | Hacker News Reader

Embedding Truffle Languages

nirvdrum.com

38 pointsnirvdrum21 comments

If you've heard of Truffle or Graal you probably know that it can run as a JIT or produce a standalone executable, but there's actually so many more configurations it can run in - it's a true universal runtime system.

I wish Graal target wasm platform

It has an LLVM IR backend, which you can then translate to WASM. Not sure if I've seen any examples of anyone doing this though.

Does it?

I know it supports executing LLVM IR - but that's not the same as a target platform.

https://www.graalvm.org/22.1/reference-manual/llvm/

Sorry, seems that you're right:

https://www.graalvm.org/22.1/reference-manual/native-image/L...

> I know it supports executing LLVM IR - but that's not the same as a target platform.

Specifically, that's a source platform, which is basically the opposite of target platform.

Graal also has LLVM as a target platform, is what I said.

Well, that's new. That is really cool and opens up some neat usecases.

That's what you said:

> It has an LLVM IR backend [ie, LLVM IR as a target platform]

The quote in my previous comment was from yarg, and (as stated) was describing a source platform.

There is wasm support already. https://www.graalvm.org/22.1/reference-manual/wasm/

That's a Wasm interpreter for the GraalVM. I believe the OP is looking for Graal to generate Wasm instructions rather than x86_64 or AArch64 code.

What for?

That implies other runtime will execute them.

Graal is a runtime, what would that help?

There are already enough of WASM runtimes, Graal itself, as others pointed out.

> what would that help?

For example to let you run Java code in a browser.

Still don't get why Graal, which is mostly something like LLVM for Java matters in such scenario.

What one wants is a .class to WASM converter and there already a couple of them to choose from, namely TeaVM and CheerpJ as the most advanced ones.

> What one wants is a .class to WASM converter and there already a couple of them to choose from, namely TeaVM and CheerpJ as the most advanced ones

Do they provide the kind of best-in-class whole-world-analysis optimisations that Graal does?

But we should take a look at what they produce some time!

I think in practicality Graal's LLVM output is not terribly platform agnostic, as LLVM lacks some expressiveness for the thing that Graal needs to do for deoptimisation.

That task is taken over by browser JIT engines, hence I still don't get why Graal should be generating WASM bytecodes to start with.

Naturally consuming them as yet another WASM runtime makes sense, but that isn't what OP was asking about.

> That task is taken over by browser JIT engines

But you can't apply high-level optimisations by the time all you have is WASM bytecode and all your high-level structure is gone. You also don't have enough time to apply these optimisations if you're JIT compiling.

I see that as the role of a Java compiler, or the bytecode converter.

Maybe if we were talking about SubstrateVM, but even then, I don't get why that should be something to increase its code complexity of backends.

> Maybe if we were talking about SubstrateVM

Yeah that's what I was talking about.

> I don't get why that should be something to increase its code complexity of backends

Backends are pretty well-isolated parts of the code. You can see how simple the LLVM one is for example.

But it would run badly. WASM isn't designed to do the sorts of things a Graal backend needs (at least not fast).

It'd be much more direct to ship apps directly to the desktop, or to develop a kind of Graal browser. You could even fork Chromium to add GraalVM inside Blink. Trying to put Java into the browser is a dead end though, browser makers won't tolerate competing platforms they don't control.

I haven't personally tried this, but being able to target things like Cloudflare Workers seems like an interesting use case to me.

Reply on news.ycombinator.com