Using Truffle for the blz programming language

[Christian Humer]

Hi Alex,

Thank you for your questions. And thanks for using Truffle for your
language!

> However, I cannot seem to get truffle to generate these classes (when I
add annotations like @NodeInfo and run a mvn package), is there something
else I need to run?

No, configuring like the simple language pom[1] here should do the trick.
Did you also checkout our IDE setup guides?[2]

> Is it possible to keep these boxed values, and if so will it be at the
cost of performance?

Boxing elimination is primarily done for interpreter performance (running
the interpreter as Java application) and not so much for compiled
performance (=peak performance). That being said, we have found that boxing
elimination is a very important factor on interpreter performance, that is
why some of our languages, like Graal.js, do primitive boxing elimination.
But I'd recommend to not worry about boxing elimination in the interpreter
when you get started. Graal does an excellent job during compilation,
removing many of the allocations with Partial Escape Analysis.

Please note: Your current Value abstraction will just make type
@Specializations useless, as it is always Value. You can still use
expression guards like this: (@Specialization(guard="value.isString()")
instead. But it is a bit more cumbersome.


> How viable is it to use the version of Graal in JDK 9/10? Is it even available
on windows? I would like to not exclude users for the sake of speed.

You will not need to exclude any users. Every Truffle interpreter can run
on a stock JDK without Graal installed. You just put the graal-sdk.jar and
the truffle-api.jar on the classpath together with your language and it
will work (but without Truffle compilation). It should also work on Windows
but we don't test this atm. You cannot run with graal-sdk and truffle on
the classpath when running with GraalVM. As GraalVM already ships with it.
SimpleLanguage has a script to detect whether its a stock JDK or GraalVM
here[3]. We are currently simplifying this script a bit.

We have several issues to fix for Windows and the build script. The
versions of Graal that are included with JDK 9/10 are currently not
compatible with Truffle. So you can not yet benefit from Graal partial
evaluation (compilation). But we plan to support this in the future.

[1]
https://github.com/graalvm/simplelanguage/blob/master/language/pom.xml#L29
[2] http://www.graalvm.org/docs/graalvm-as-a-platform/implement-language/
[3] https://github.com/graalvm/simplelanguage/blob/master/sl

Feel free to checkout the Gitter chat as well for more questions:
https://gitter.im/graalvm/graal-core

Thanks

- Christian Humer




On Wed, Apr 18, 2018 at 10:18 PM Alex Gravenor <caalex101 at gmail.com> wrote:

>  Hi all,
>
> I am the creator of blz <https://github.com/blazingkin/blz-ospl/tree/v2.6
> >,
> an interpreted programming language written in Java.
>
> I've been looking to transition blz onto Truffle for a while, but I have a
> few questions before I can do so.
> I'd also appreciate any advice about working with Truffle, as I am only an
> undergrad and I'm mostly making it up as I go. ��
>
> My first question is about the truffle-dsl processor.
> Both simple language
> <
> https://github.com/graalvm/simplelanguage/blob/master/language/src/main/java/com/oracle/truffle/sl/nodes/expression/SLDivNode.java
> >
> and graal.js
> <
> https://github.com/graalvm/graaljs/blob/master/graal-js/src/com.oracle.truffle.js.nodes/src/com/oracle/truffle/js/nodes/binary/JSDivideNode.java
> >
> use abstract (in the Java sense) expression nodes, supposedly relying on
> the truffle-dsl processor to create the NodeNameGen concrete classes.
> I've been trying to transition the blz nodes
> <
> https://github.com/blazingkin/blz-ospl/blob/v2.6/language/src/com/blazingkin/interpreter/executor/astnodes/DivisionNode.java
> >
> to a similar system.
> However, I cannot seem to get truffle to generate these classes (when I add
> annotations like @NodeInfo and run a mvn package), is there something else
> I need to run?
>
> Next, I was wondering about the convention of boxed / unboxed values.
> For blz, I have a Value
> <
> https://github.com/blazingkin/blz-ospl/blob/v2.6/language/src/com/blazingkin/interpreter/variables/Value.java
> >
> class that essentially boxes values with a datatype.
> It seems like the convention with Truffle is to make specializations for
> unboxed values.
> Is it possible to keep these boxed values, and if so will it be at the cost
> of performance?
>
> Finally, I have some concerns about portability.
> The only versions of Graal available from OTN
> <
> http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html
> >
> are for UNIX systems.
> I've tried building Graal on a windows machine, but I ran into several
> issues with the python script in mx not being compatible with the windows
> filesystem. (I have some fixes that I may put in a PR)
> How viable is it to use the version of Graal in JDK 9/10? Is it even
> available on windows?
> I would like to not exclude users for the sake of speed.
>
> Y'all are doing super exciting work. Congrats on the 1.0 release!
>
> Thanks,
>
> Alex Gravenor
>