On: Creating a JVM language

[pron]

The next step is using Truffle to bypass bytecode generation and interact directly with Graal -- HotSpot's next-gen (JIT/AOT) compiler -- and its amazing optimizations:

Writing a Language in Truffle: http://cesquivias.github.io/tags/truffle.html

[jakubdziworski → pron]

I read a bit about truffle combined with graal (before deciding to go with asm) but could not find many useful resources. Seems like it is a very new stuff. I will definitely take a look at those blog posts.

[chrisseaton → jakubdziworski]

Graal will be usable in Java 9, and Truffle has been relatively stable for a while now. If you are doing a project from scratch I would highly recommend trying them out.

You can talk to the Graal and Truffle teams directly on https://gitter.im/graalvm/graal-core if you can't find where to start or have questions.

I lead the Ruby implementation https://github.com/jruby/jruby/tree/master/truffle which along with FastR is one of the most sophisticated open-source users of Truffle and Graal.

[alblue → chrisseaton]

Chris came to give a talk at the DocklandsLJC recently, which gives a great intro to these to technologies.

http://docklandsljc.uk/2016/04/truffle-graal-clojure-neo4j.h...

[twic → pron]

When you say "bypass bytecode generation", you mean abstract away from it, right? Graal still generates bytecode, doesn't it?

[pron → twic]

No, Graal emits target instructions for its backend (usually machine code for CPUs or GPUs, but it could emit anything). Java bytecode is one of Graal's two frontends, the other being Truffle. I believe both Truffle and byteocde are then represented as internal Graal ASTs. In any event, Truffle is not translated to bytecode (although the opposite is possible: you could write a Truffle interpreter for bytecode).

I guess it's also theoretically possible to have a bytecode backend for Graal, but that wouldn't make sense except maybe to make Truffle languages executable on non-Graal JVMs for compatibility; I don't know how useful it would be because I think Truffle has an interpreter fallback.

[KMag → pron]

> I believe both Truffle and byteocde are then represented as internal Graal ASTs.

I hope Graal converts both JVM bytecode and Truffle ASTs directly into an internal SSA form, without first building an AST from JVM bytecode.

Actually, come to think of it, if I were a Graal author, I'd be tempted to have a JVM bytecode interpreter, two non-optimizing Wirth-style compilers that emitted native code directly from JVM bytecode and Truffle ASTs, two middle-ends that generated SSA from JVM bytecode and Truffle ASTs, and an optimizing SSA-based native code back-end.

> I don't know how useful it would be because I think Truffle has an interpreter fallback.

Every Truffle AST node contains Java code for evaluating that node, so a tree-walking interpreter is trivial.

[CrystalGamma → pron]

Graal is comparable to RPython in the PyPy system isn't it?

[pron → CrystalGamma]

I think that Graal+Truffle is comparable to RPython, as Graal is the actual compiler, and Truffle is the API for interacting with Graal, i.e. analogous to the RPython language.