OpenJDK Proposes Project Galahad to Merge GraalVM Native Compilation

Re:OpenJDK Proposes Project Galahad to Merge GraalVM Native ... by hrpnk on Wednesday December 21, 2022 @04:19PM (#34086549)

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...

[ Parent | on HN ]

Re:OpenJDK Proposes Project Galahad to Merge GraalVM Native ... by kaba0 on Wednesday December 21, 2022 @06:04PM (#34087562)

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

[ Parent | on HN ]

Re:OpenJDK Proposes Project Galahad to Merge GraalVM Native ... by actuallyalys on Wednesday December 21, 2022 @07:19PM (#34088147)

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.

[ Parent | on HN ]