OpenJDK Proposes Project Galahad to Merge GraalVM Native Compilation

https://www.infoq.com/news/2022/12/openjdk-galahad-Dec22/

by mfiguiere • 4 years ago

152 68 4 years ago

adra• 4 years ago

I don't see too many immediate term improvements from what we have today, but I do see GraalVM to be just different enough from mainline OpenJDK releases to question exploring the features of that build (in JVM or native modes). I poked at the release from time to time between 19 and 22 but always ended up going back. If this can improve that story, I'd say it's a win for all. Of course I'm not sure what this changes in regards to Oracle's extended paid version of the GraalVM runtime.

Alupis6• 4 years ago

GraalVM will mostly benefit those who are building and deploying Function/Serverless and Microservices most - the native compilation really shines in that space (for near-instant start times and footprint reduction).

For anyone else, the normal JVM is likely a better choice for now - the tech built in there is very mature and battle tested.

With that said - baking a bunch of GraalVM features into the normal JVM is nothing but good for everyone. Native AOT compilation does have it's uses outside microservices/serverless, and some cross-pollination of VM ideas is a great idea.

cogman10• 4 years ago

There are a lot of other neat parts for graal that will likely be beneficial. One of the big benefits of graal is that it makes implementing guest languages a snap (via the truffle framework).

So you can get all the operational benefits of the JVM + a nice set of languages to play with along with interopt cross language (python calling java calling ruby calling perl, etc).

Here's the languages they already have.

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

threeseed• 4 years ago

building and deploying Function/Serverless and Microservices most

For those you may be better with IBM OpenJ9:

https://www.eclipse.org/openj9/

It also integrates with CRIU so you can almost instantly start/stop the JVM:

https://blog.openj9.org/2022/09/26/getting-started-with-open...

aseipp• 4 years ago

GraalVM is a bunch of components, but the most important one are 1) Graal, a library in Java that is a code generator and optimizer for compiler authors, 2) Native Image, a tool which turns Java programs into native executables via Graal, and 3) Truffle, a tool for implementing languages in Java that then get code generated, again by Graal

"GraalVM" is the umbrella name of all these things packaged together, together with a couple languages implemented in Truffle. That's what you download when you go to the website.

Galahad is a proposal to merge the Graal code generator library in Java, into OpenJDK's codebase, so that it is developed in tandem and comes with first-class support. And none of the other things, for now (Native Image will come later.) But you can also do this today: you can instead configure a stable LTS release of Java to use Graal as the code generator for the HotSpot VM, as an alternative to C2. It's a little bit of work to do so, but you can use any compliant OpenJDK build and test it out. Galahad will just make this an "out of the box" option rather than having to get Graal from Maven or whatever.

So, you can just test things incrementally and see if Graal gives performance improvements over C2. You don't need to throw out your whole existing JVM, it's mostly just a new maven dependency. That's a much simpler and more targeted change, if you haven't given it a try (mostly by fiddling with some JVM -XX flags, as usual.)

hrpnk• 4 years ago

The challenge with GraalVM runtime is that there are differences in licensing. What was great about Java is that only for specialized use cases, one had to invest in a paid runtime. GraalVM moves essential features known from Java Runtime into an Enterprise Edition.

From GraalVM docs [1] on memory management: "The G1 GC (only available with GraalVM Enterprise Edition) is a multi-threaded GC that is optimized to reduce stop-the-world pauses and therefore improve latency, while achieving high throughput. Currently, G1 can only be used in native images that are built on Linux for AMD64."

[1] https://www.graalvm.org/22.2/reference-manual/native-image/o...

kaba06• 4 years ago

That particular one (and most differences) are only related to native image generation, not to Graal, as a JIT compiler.

actuallyalys• 4 years ago

I think tweaking the garbage collector when running on native is a specialized use case. Anecdotally, the projects using native image I'm aware of don't tweak the garbage collector settings that are available in the community version at all. If throughput is critical enough to warrant garbage collector fine tuning, there's a decent chance you'll run it on a VM anyway. Of course, there are exceptions, but I don't think this is a limitation for most projects.

That being said, most of the JVM projects I'm very familiar are written in Clojure, so they may well be outliers compared to Java or other JVM languages.

thangalin• 4 years ago

It'll help build cross-platform desktop applications. In theory, it'll streamline using GitHub Actions to produce platform-specific binaries, such as my FOSS Markdown editor KeenWrite[0], without having to have a copy of every target operating system.

To my knowledge, cross-compiling "native" Linux and Windows binaries using Java requires duct tape, chewing gum, and warp-packer.[1][2] If there's another way to cross-compile a Java application into a standalone binary for multiple target platforms, do tell!

GraalVM isn't a panacea. For example, GraalVM cannot compile Renjin[3], a pure Java R interpreter, which means switching from Renjin to FastR. Not trivial. Other sinkholes likely lurk that'll only reveal themselves when walking through the weeds.

[0] https://github.com/DaveJarvis/keenwrite

[1] https://dave.autonoma.ca/blog/2020/06/29/write-once-build-an...

[2] https://github.com/dgiagio/warp

[3] https://github.com/bedatadriven/renjin/issues/564

anentropic• 4 years ago

I'm actually wanting to do this with Graal at the moment ("using GitHub Actions to produce platform-specific binaries")

As far as I can tell Graal does not have cross-compilation ability currently (there is an open issue here: https://github.com/oracle/graal/issues/407)

kasperni3• 4 years ago

The title of the article is a bit misleading. The goal is first to merge GraalVMs JIT compiler (as an alternative to C2). Then later to bring in the AOT compiler.

pulse72• 4 years ago

After this merge we will have JVM implemented mostly in Java (aka "self hosted"). Currently about 1% of the JVM runtime is implemented in C and this will be replaced with instrumented Java code (including garbage collectors). This means that only one runtime will be maintained in the future and Java developers will do it (and not C/C++ developers which are harder to get). It will be much easier to implement and test new memory management mechanisms than it is today.

If they also decide to merge support for other languages (including WASM and LLVM) we will be able to run everything that compiles to WASM and to LLVM on the same runtime - in the same JVM. So we will get another "Docker Without Containers"...

EDIT: It seems that I am wrong with the above 1% statement. I meant that about 1% of the Java standard library is written in C/C++. Regarding JVM: I guess that the whole HotSpot VM will be replaced with GraalVM in the future and when this happens, majority of the JVM code will be in Java.

Alifatisk2• 4 years ago

Is C devs really hard to get?

Alupis6• 4 years ago

C devs? No. Competent systems-level C devs - yes.

The embedded and systems space are hard and require special talent and knowledge. You can't just take some front-end React developer and get them writing quality systems C code in a weekend... people spend entire careers in that space, and the number of people interested in that work shrinks by the year (look at all developer surveys).

jalcazar• 4 years ago

not really hard just harder than Java

mike_hearn2• 4 years ago

Where did you get the 1% figure from? HotSpot has millions of lines of C++, that seems far too low.

Graal doesn't affect memory management. It's a JIT compiler, not a GC. Although there's a relatively simple GC written in SystemJava for native images, G1, ZGC and Parallel will continue to be the standard GCs in the regular JVM for the foreseeable future and they are all written in C++.

taeric2• 4 years ago

To add to your question, assuming the tooling at github is ok, it has ~20% as c/c++ for https://github.com/openjdk/jdk. I would think most of that would be concentrated in the hotspot code, but I don't know. Would be delighted to know what the original post was referring to.

kasperni3• 4 years ago

Currently about 1% of the JVM runtime is implemented in C

The JIT is probably half of the VM and is written in C++.

Github [1] says (for the whole JDK, not just the VM): Java 75.1% C++ 13.4% C 7.4% Assembly 2.3% Objective-C 0.4%

[1] https://github.com/openjdk/jdk

morelisp2• 4 years ago

It's surprising to me that effective knowledge of C and/or C++ is the stumbling block for contributing to the core of the JVM.

I work at a company with one large C++ codebase, and also many Go projects where C and C++ knowledge are helpful. We have trouble hiring good C++ developers, because our candidate pool starts as "people who want to write web applications".

But if you're already restricted to people who want to work on an extremely mature compiler, VM, and JIT - is lack of C knowledge really what's making it hard to hire people? These are people who are likely to end up reading kernel code and C-defined ABI documentation and etc. etc. even if the codebase is 100% Java...

lmm2• 4 years ago

The people who believe in and care about Java tend to be Java people; C-oriented people tend to be rather anti-Java.

wiseowise2• 4 years ago

We have trouble hiring good C++ developers, because our candidate pool starts as "people who want to write web applications".

You have trouble hiring good C++ developers, because you don’t pay enough.

kaba06• 4 years ago

It's surprising to me that effective knowledge of C and/or C++ is the stumbling block for contributing to the core of the JVM.

Parent is just talking out of his/her ass.

vips7L3• 4 years ago

Regarding JVM: I guess that the whole HotSpot VM will be replaced with GraalVM in the future and when this happens, majority of the JVM code will be in Java.

I believe this is still incorrect. GraalVM is HotSpot with the Graal JIT compiler and the truffle languages.

pulse72• 4 years ago

OK. Then I guess that the whole HotSpot VM will be replaced with GraalVM + Substrate VM in the future... :)

Alifatisk2• 4 years ago

I’ve had thoughts about trying GraalVM with a old Ruby project using (truffleruby) but I found the docs to be a bit rough.

aardvark179• 4 years ago

Pop over to the Graalvm slack and let people know what you tried and what could Be improved.

coldtea2• 4 years ago

Despite this, there has always been interest in the possibility that Java programs could be directly compiled to machine code and execute standalone without a JVM.

Cue the "you could always do that with some niche commercial product all 3 people used" from certain HN circles -- you know you who are :)

coldtea2• 4 years ago

Despite this, there has always been interest in the possibility that Java programs could be directly compiled to machine code and execute standalone without a JVM.

Cue the "you could always do that with some semi-supported neglected FOSS like GCJ or some niche commercial product all 3 people used" from certain HN circles -- you know who you are :)

touisteur• 4 years ago

Ahem PTC PERC still in use, and we're probably at least... 10 people using it!

icedchai• 4 years ago

I remember doing that with a commercial product in the late 90's. I think it was called TowerJ? I ran it on a Sparc.

OpenJDK Proposes Project Galahad to Merge GraalVM Native Compilation

Related Stories