grashalm

The Graal compiler is compiling Java code to faster machine code on top of the JVM. Also GraalVM's JavaScript implementation uses an entirely different approach by using Truffle for its implementation making it significantly faster. Also GraalVM ships with Node.js support, tooling and other languages.

Here is a full list of reasons: http://www.graalvm.org/docs/why-graal/

Here are some (maybe a bit outdated, but independent) benchmarks comparing it to Nashorn: http://blog.nidi.guru/tech/javascript/2018/04/02/javascript-...

We have some way to go to beat V8.

Yes you will be. But we use a different interface. Checkout this guide: http://www.graalvm.org/docs/reference-manual/polyglot/

Select your start and your target language and it will show you an example. Its a very basic example, but it basically works with all Java types. We will provide better docs soon.

Thanks for the feedback. We will definitely improve the polyglot docs in the next weeks. There is lots more to show.

Are you calling from Java? Then there are more examples here: http://www.graalvm.org/docs/graalvm-as-a-platform/embed/

Also some of the examples on the website use interop: http://www.graalvm.org/docs/examples/

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here:

Graal: https://github.com/oracle/graal (GPLv2 with CPE)

JavaScript with Node Integration: https://github.com/graalvm/graaljs (UPL - BSD license)

Ruby: https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL)

R: https://github.com/oracle/fastr (GPLv2)

Python: https://github.com/graalvm/graalpython (UPL - BSD license)

LLVM/Sulong: https://github.com/graalvm/sulong

Yes. Its behind the native-image command. http://www.graalvm.org/docs/getting-started/#native-images

Nobody is ever 100% right. I have a hard time swallowing such sentences.

Bad title. Datastructures always come with trade offs. In this case Insertion Speed and memory efficiency vs iteration and random access Speed.

Agreed. Some cs conferences verify artifacts these days, which is a good first step.

I am thinking of huge endeavors like building an asic or huge complex systems like virtual machines. Not always a comparable system for Repetition is available and must be built from scratch. Affording such rebuilds require huge sums.

Of course nobody does consider others not capable enough. Its just that there are not so many people experienced enough to build certain systems in a decent amount of time.

Sometimes in cs if your research is embedded in a huge ecosystem, it can become quite expensive to reproduce results. I mean proper reproduction, not just rerunning the Benchmarks. If you are dealing with complicated stuff, the reproducer might also just not be able to do the same thing technically.

Easy to reproduce [1]. Just remove the a in the end and your timeout disappears. Anybody knows which regex engine they used?

[1] http://regexr.com/3drn3

These people and their gamified minds... ;)

Yes this brand new. Have fun!

This is quite outdated. here is an overview of Graal/Truffle papers and tutorials: https://wiki.openjdk.java.net/display/Graal/Publications+and...

If you do it in a language specific way, you would probably need to catch those TC exceptions when calling into functions of your language. That is very easy to do, as every Truffle language controls how its functions get called in a foreign languages.

What was your title? Without a good one, your post might have been just skipped by most.

There was a patch for coroutines on the JVM some time ago. Unfortunatly it did not make it into the platform. No reason why it could not be added to the JVM.

SubstrateVM solves the embeddability part.

Partial Evaluation requires very precise knowledge of the bytecodes which are feeded into it. Having eg. Scala abstractions showing up suddenly would be quite annoying. Java is closest to bytecodes thats why we use it for Truffle interpreters.