Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraalVM for JDK 21

medium.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: GraalVM for JDK 21

#71

Post by mike_hearn »

soulbadguy wrote: post #56
logicchains wrote: post #49

Earlier quoted context omitted.

>With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?

Possible, but i don't think it's very likely. Project Valhalla is a big umbrella term but couple of important points : - The new value type don't garanty flat memory representation, so might have some corner cases which are not properly optimized - The monomorphization or java vs C++ is still a big advantage for c++ - The compiler optimization of LLVM/GCC are still quite a bit better (in term of generated code) vs jv…

I'm not sure any of those are actually quite right.

Valhalla supports flattening, that's the whole point of it. To get that you need to have a type declared as a value type, and then put it into a non-null variable, field or parameter. At least that's how the current prototype works. If you do that then the compiler will fully inline the allocation into arrays, containing objects/structs, or the stack.

Valhalla started with monomorphization prototypes, although that went silent years ago. I don't know if it'll be delivered in the first version. But, it's an intended goal of the project to deliver.

As for the final point, could you evidence that? It's very hard to do direct comparisons here because they're usually compiling very different languages and Graal hasn't been optimized for C++. For example, Graal can compile many languages LLVM just doesn't even try to. Also, you'd really need to compare against the Oracle GraalVM (née GraalVM Enterprise) to see the best of what it can do. I'm curious what comparison you're thinking of when you say that, as Graal is an extremely advanced compiler by any measure.

Re: GraalVM for JDK 21

#72

Post by mike_hearn »

logicchains wrote: post #49
mike_hearn wrote: post #16

Earlier quoted context omitted.

gcj had a lot of problems beyond needing configuration of reflection metadata. It used a full reimplementation of the standard library, and it was never adopted by the wider Java community being largely just Red Hat's strategy for creating a fully open source Java implementation rather than something offering specific benefits to Java developers. In particular people thought it'd lead to faster code, but GCC was neve…

>With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?

Valhalla and the vector API for SIMD, yes. In theory, at that point, the only major performance difference between them would be GC vs manual memory management. Also: code size.

One interesting experiment that'd be worth trying is generating value types that wrap memory segments, as that's the new manual memory allocation API. You can do pretty sophisticated manual allocation with arenas and stuff, but you can't allocate Java objects into those segments. What you can do though, is create a "struct" using VarHandles that you can cast the segment to which then reads/writes through to the segment. This leads to the question of whether you can make a nice wrapper around such value types that yield C++ style manual memory allocation.

Re: GraalVM for JDK 21

#73

Post by mike_hearn »

foooobaba wrote: post #61
pregnenolone wrote: post #51

I use Graal Native to AOT compile my JavaFX applications. It works surprisingly well.

I was considering this, working on a new javafx app for a side project. Using java 17, and generating binaries with fxlauncher/jpackage/wix is not working great imo. Any good recommendations on tooling for using the graal route? I develop on linux but most users will be on windows. It would be great to not have to use windows vm for building the binaries (but i can if needed ofcourse).

Take a look at https://conveyor.hydraulic.dev/, it supports JavaFX apps and can build Windows/Mac packages from Linux.

It can't do native images from those though.

Re: GraalVM for JDK 21

#74

Post by pjmlp »

soulbadguy wrote: post #56
logicchains wrote: post #49

Earlier quoted context omitted.

>With this new release the compiled images can not only be faster than JIT compiled Java (wow) but also use way less memory and start instantly Does this mean that once Project Valhalla lands, Java via Graal will be a viable competitor to C++ for tasks requiring extremely high performance?

Possible, but i don't think it's very likely. Project Valhalla is a big umbrella term but couple of important points : - The new value type don't garanty flat memory representation, so might have some corner cases which are not properly optimized - The monomorphization or java vs C++ is still a big advantage for c++ - The compiler optimization of LLVM/GCC are still quite a bit better (in term of generated code) vs jv…

There are JVM implementations, like Azul, that use LLVM for their AOT/JIT compilers, so the last point isn't really a plus for C++.

Java like C and C++, enjoys multiple implementations.

Regarding monomorphization, it is still open how much Valhala will go into that front.

Even if Java will never be as good as C++ in generics, there are several other issues that usually tend to have Java chosen for instead of C++, even if C++ wins in the microbenchmark games.

Likewise most options for running Java on the GPU aren't as feature rich as C++, and that is certainly an area where C++ will be dominating in decades to come.

Re: GraalVM for JDK 21

#75

Post by pharaohgeek »

gzalo wrote: post #17

We tried to use it to improve AWS lambda startup times but desisted as it was a pain to use it with an existing app. It required too many tweaks as there are waay too many things that rely on reflection :( Things that broke include: JSON (de)serialization using Jackson, validations using hibernate, validator, AWS SDK, and even simpler libs like picocli... It could be quite useful for a set of simpler apps though

Look at the Quarkus framework. It's designed with Graalvm native in mind, so it knows how to handle Jackson, AWS, etc. and compile them to a native binary. I'm using it in production with a native-compiled Lambda that calls other AWS services. It works GREAT!

Re: GraalVM for JDK 21

#76

Post by grashalm »

hueho wrote: post #36
adra wrote: post #33

Earlier quoted context omitted.

Everything has a cost though. The one thing we lose is the ability for hotspot to change its mind and recompile code based on usage patterns I've toyed with graalvm for some uses and ended up with lost performance. Also a key note is that it only supports a pretty naive serialgc right now which is a big limitation. Bellsoft has a parallelgc which probably plays a little better, but we're always going to need to play…

The serial GC is a limitation of the community (OSS) edition. The enterprise proprietary version has G1 support. I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.

With the new GFTC license, we hope G1 is much more accessible now.

Re: GraalVM for JDK 21

#77

Post by cxr »

sgammon wrote: post #63
amelius wrote: post #57

Warning: Graal is owned by a law-firm called Oracle (that happens to employ some programmers too).

they opened up the license...

Sun themselves (not Oracle) also "opened up" their Java implementation as GPL 15 years ago. It didn't stop Oracle spending years sowing their own uncertainty and doubt and trying to claim billions of dollars in damages from Google in a lawsuit where McNealy sat on the stand and testified that the GPL licensing didn't allow commercial use.

Re: GraalVM for JDK 21

#78

Post by chrisjc »

alberth wrote: post #8

What’s the latest on Truffle/Ruby supporting Rails? Wouldn’t this provide massive gains for the Rails ecosystem once delivered? (And with the GraalVM licenses changes to be more favorable/permission, I have to imagine there would be significant adoption)

    TruffleRuby runs Rails and is compatible with many gems, including C extensions. TruffleRuby is not 100% compatible with MRI 3.2 yet. Please report any compatibility issues you might find. TruffleRuby passes around 97% of ruby/spec, more than any other alternative Ruby implementation.
https://www.graalvm.org/latest/reference-manual/ruby/#curren...

Re: GraalVM for JDK 21

#79

Post by the-alchemist »

I think the biggest improvement in GraalVM 21 is profile-guided optimizations (PGO) in both aarch64 and amd64.

This means you can take full advantage of ARM cloud services like AWS Graviton (sp?) services for lower cost.

Also, looks like the Java Vector API (JEP338) has been optimized.

So, same code on your Raspberry Pi and AWS Graviton, cool.

Re: GraalVM for JDK 21

#80

Post by MrPowerGamerBR »

gavinray wrote: post #15
mlinksva wrote: post #11

Earlier quoted context omitted.

https://www.graalvm.org/latest/security-guide/polyglot-sandb... looks very interesting though enterprise (not open source I assume?) only and maybe only for executing javascript? Or do I misunderstand, or is there other sandboxing support?

Many of the configuration settings set by a sandboxing policy are available when creating Polyglot contexts with the Community Edition.

Are you sure? I created a JavaScript Polyglot context in Java with GraalJS CE 21 and...

> Exception in thread "main" Polyglot sandbox limits can only be used with runtimes that support enterprise extensions. The runtime 'GraalVM CE' does not support sandbox extensions.

Post reply on HN