6 ms·
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 inve
by hrpnk 4y 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/optimizations-and-performance/MemoryManagement/ https://www.graalvm.org/22.2/reference-manual/native-image/o...
- kaba0 4y agoThat particular one (and most differences) are only related to native image generation, not to Graal, as a JIT compiler.
- actuallyalys 4y agoI 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.