grashalm

Which isolates do you mean? Support for Native image isolates is included in CE.

There are some features like polyglot isolates that are currently EE, but they are just a use of native image isolates.

No, there is only a frontend. There is a JavaScript backend though. I hope the GC proposal for WASM ultimately goes through to enable a backend in WASM too.

I get that some ui issues are hard to solve given that Jira is heavily customizable and backwards compatibility is a real issue. But for ui performance there is really no good excuse.

I am sorry to hear you did not succeed in building your own language. I have to admit it is quite a steep learning curve. If you decide to retry do not hesitate to hit us up with questions on the community slack. We are a helpful bunch.

Also I will drop my truffle seminar shamelessly here for you to watch: https://youtu.be/pksRrON5XfU

That is incorrect. JVMCI is still in OpenJDK and is the only thing required to run Graal. You need to put Graal as jar from Maven on the upgrade-module-path since JEP 410 since it's no longer there by default but this is the only thing that changed.

So you can continue to use Graal as your last tier compiler or to compile Truffle languages on OpenJDK.

GraalVM was born in Oracle Labs, the spiritual successor of Sun Labs. There are many great innovations coming from Oracle Labs: https://labs.oracle.com/pls/apex/f?p=94065:INTRO::::::

Also join us on Slack if you have questions: https://www.graalvm.org/slack-invitation/

GraalVM dev here. Note that Java on Truffle is fully Open Source and available on Github.

If you can read Java code and you are interested in how it is implemented start reading here: https://github.com/oracle/graal/blob/espresso/espresso/src/c...

If you are interested in a deep dive into the Truffle technology and are interested in why it makes sense to implement a language on top ofTruffle checkout my recent Rebase talk for a really long answer: https://youtu.be/O4icaN9khp4

If you don't have enough time for an 1h talk checkout my summary tweet: https://twitter.com/grashalm_/status/1212763944043139072

Well, it is necessary to expose this to language implementations to reach good performance. If we could reach the same performance otherwise, we would not expose it, as it makes implementing Truffle languages more complicated. Unfortunately automating the specializing part is an unsolved research question for a method based compiler (deserves its own PhD). Other trace based meta-compilation approaches (e.g. PyPy) have an advantage here, but disadvantages in other areas.

Truffle team lead here. Yes we are working full steam on improving warmup and delays caused by going back to the interpreter in unexpected cases. Expect bigger improvements in this area soon.

That being said, we cannot do it all on the Truffle side without help of the language implementation. Truffle languages speculate on certain aspects of the program data. If they do so, then we need to deoptimize and invalidate the optimized code when this speculation is violated. So the stability of the language implementation really is an important factor. Questions like "do we need to speculate on this value being constant or does give us enough benefit to justify the deoptimization overhead?" need to be answered by the language implementation and not the Truffle framework. Afaik this was not a priority for TruffleSqueak so far, but it might be in the future. So there are potentialy future improvements also on the TruffleSqueak side.

You mean partial escape analysis and scalar replacement for reduced heap allocation rates. Partial evaluation is something else, also pretty useful but for other reasons.

Don't worry TruffleRuby has a strong team that is dedicated to deliver. Besides, Chris is still working on TruffleRuby in his new role.

Indeed you need to buy the enterprise version for use in production. This is funding the project so that the majority of the features can stay open source.

> No mention of Windows

Indeed. That description should be fixed. One click away there is a Windows build: https://github.com/oracle/graal/releases

This is about using native-image for the Graal compiler when used as a JIT in HotSpot. There are Windows builds for this available here[1]. Not sure what you mean by position independent code in the context of libgraal. But I don't think it is relevant.

[1] https://www.graalvm.org/downloads/

Graal-dev here,

We are working with a very high priority on JDK 11 support. We should be able to ship it in a few months from now.

> So is graal polyglot already compatible with newer JDKs and it's just native image generation that's blocking the upgrade?

Not just. We also need to upgrade the JVMCI version we use in order to support libgraal (Graal compiler as native-image in HotSpot). Also, modules make everything a little bit more complicated as well.

Contrary to popular believe, automatic loop vectorization is not as important to most Java workloads as one might think. It gets a lot of visibility as it causes significant peak performance differences in micro-benchmarks.

In the end, you should not trust standard benchmarks and definitely not micro-benchmarks. Do perform tests with your own workload.

> I think MoarVM/NQP are strikingly similar in their approach

Does MoarVM use a meta-compilation technique? Pypy for example uses meta-tracing and Truffle uses Partial Evaluation to get from an interpreter specification to dynamically compiled code without duplicating the language logic. If yes, could you please point me to further information?

Meta-compilation is the primary innovation in Truffle. It allows to compose languages together and to compile them as one unit.

If you want to know more about the Truffle approach to meta-compilation see this PLDI paper from 2017[1].

[1] http://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-tru...

Neither. You download EE or CE from graalvm.org. Then you install using the component installer.

gu -c install org.graalvm.ruby

or from a local file

gu install ruby-installable-linux-amd64.jar

GraalVM EE has a MacOS version that is free for evaluation uses. http://www.graalvm.org/downloads/

There are technical reasons we cannot have a CE for Mac OS as well. But we are working on that.

- FastR is around for several years. Language support is pretty much done. Its mostly about getting to run CRAN packages that use native extensions.

- Graal.python is pretty new and its really early days. So even basic language things might break right now. But we are investing a lot of resources in Python support.

You can check for compatibility of packages here (not yet for Python): http://graal-staging.us.oracle.com/docs/reference-manual/com...

Truffle tech lead here. Happy to hear you are not giving up :-) Do you mind if I include your language on the experiments list?

BTW.: I'd recommend upgrading one Truffle release at a time. So it should always continue to compile. Just fix the deprecation warnings and continue with the next version until you reached the last version. We always keep deprecations for at least one version before we remove/break APIs.

If you want to discuss something in more detail feel free to join us in the Gitter chat: https://gitter.im/graalvm/graal-core

We don't bite.

If you can run a HotSpot JVM there then also GraalVM should work. I don't think we tested that.

I posted all the license below in a comment.

We don't convert. We have defined a contract that all languages can work with (quite a challenge and still evolving).

From the website:

> In order to provide foreign polyglot values meaning in languages we have developed the so-called polyglot interoperability protocol. This interoperability protocol consists of a set of standardized messages that every Graal language implements and uses for foreign polyglot values. The protocol allows GraalVM to support interoperability between any combination of languages without requiring them to know of each other.

This technique is based on some research we did in 2015: http://chrisseaton.com/rubytruffle/dls15-interop/dls15-inter...

Thank you for those questions.

> Can I AOT with this (via SubstrateVM) and deploy to "mobile" targets, and specifically iOS?

Technically there is no reason to not support it. But support is not implemented yet.

> Are there any examples of embedding GraalVM in an existing native application (such as the noted idea of having GraalVM accessible inside of MySQL)?

Yes. Oracle MLE[1] and MySQL already work. Oracle MLE you can try already. We have a native embedding API (its very similar to the Java API). We could not yet quite finish the documentation of it for website. But its already included look for a file polyglot_api.h in the binary.

[1] https://oracle.github.io/oracle-db-mle/releases/0.2.7/

The reason why we don't build CE on Mac OS is purely technical. Its because there was no OpenJDK 8 build for Mac that we could use. We hope we can change that soon. OpenJDK builds got a lot more regular with Java version >= 10.

Currently we have the same APIs for CE and EE. So applications are easily portable between those two. We have no plans to change this.

But. You don't have to take our word for it. CE is open source and you may build, extend and maintain it yourself if you want to.

You can check libraries here: http://www.graalvm.org/docs/reference-manual/compatibility/

We don't test all of them but many.

We have considered .NET support but we are not actively working on it right now. But GraalVM is an open platform. Everyone can develop a language for it: http://www.graalvm.org/docs/graalvm-as-a-platform/

Ho wow, never heard of it. Will put it on the experiments list. Thanks a lot!

Which one was it? Can you remember? One of these?

https://github.com/oracle/graal/blob/master/truffle/docs/Lan...

If not. Please let me know.