23 ms·

RedHat Mandrel Makes Java Native

176 points by shortlived 6y ago

sudosysgen 6y ago
Wow! I think this might be good for Java video games.
- heretoo 6y ago
  To the best of my knowledge, GraalVM native images are probably slower at runtime, due to the hotspot vm being unavailable.
  - smabie 6y ago
    GraalVM native images are slower right now, but there's no reason that has to be the case in the future. I think we all have realized over the last 2 decades that though JIT compilers (like the JVM) should be theoretically faster than a traditional native code compiler, this is rarely (if ever) the case. I wouldn't be surprised if over the next 10 years most JVM code (including Java, Scala, etc) is compiled to native images. It's both clear that Oracle is pushing GraalVM hard and that it's what the consumer wants. If performance was identical, I can't think of a single reason why anyone would choose the regular JDK over GraalVM. It's not like people are slinging jars over the network between linux and windows... hell, now with WSL, that's not even a good reason either.
    - rlp 6y ago
      HotSpot uses a JIT compiler that dynamically recompiles code at runtime to speed up hot code paths. GraalVM native compilation cannot do this, and given the nature of Java's non-reified generics, it's very hard to get equivalent speeds at runtime. Profile-guided optimization is the only hope to recover some of that performance gap, and it's currently only available in GraalVM EE. I'm not sure how the benchmarks compare to HotSpot.
      - smabie 6y ago
        Why would type erasure hurt performance? Certainly expressiveness is curtailed due to Java's generics design (or lack thereof), but I wasn't aware of any performance implications.
        erik_seaberg 6y ago
        Whenever a generic class method returns an erased type and the caller tries to use it, javac has to insert a runtime check (cast) so the bytecode is typesafe. It also forces boxing of primitive types.
        smabie 6y ago
        But since the type of a function can't change at runtime, why is this necessary?
        erik_seaberg 6y ago
        Because of erasure, there is only one copy of List#get(int), and it returns Object (because there's no other upper bound). The source might say List<String> l = ... String s = l.get(0); which looks typesafe, but to pass the verifier and load, the bytecode has to accept an Object and cast it to String before using it, just like Java programmers had to write by hand before generics (this really sucked). There's not even anything stopping you from putting non-Strings in that List instance via reflection or generic casts (if you ignore the warning) or using a really old javac. You could use a checked collection but that just adds a runtime check during writes that ensures the runtime check during reads will never fail (but the bytecode verifier still won't let you remove it!)
        erik_seaberg 6y ago
        I should have written ArrayList#get. It's possible to write a class that implements List<String> in a typesafe way, but callers using the standard List interface receive an Object and have to downcast.
    - tom_mellior 6y ago
      > I think we all have realized over the last 2 decades that though JIT compilers (like the JVM) should be theoretically faster than a traditional native code compiler, this is rarely (if ever) the case. This is a very broad claim. Do you have data to support it? It would mean comparing production-quality JIT and AOT compilers for the same language, which are hard to find. I'm vaguely aware that LLVM's JIT ambitions never worked out because compile times were too slow, which (IIRC) they tried to mitigate by running fewer optimizations in JIT mode, which meant the quality of the generated code wasn't as good as AOT. I wouldn't call this production quality though, and even so it wouldn't allow you to make your claim as broadly as you are.
    - alblue 6y ago
      Actually the JIT compiler often outperforms native code when hot because the latter doesn’t typically get compiled with PGO and the JIT is effectively PGO at runtime. In addition, the JIT can perform optimisations that a native compiler can’t do, because the JIT can take different decisions if a field is null repeatedly, and thus elide the inclusion of code that supports the non null case leading to potential further optimisations due to dead code elimination and additional inlining opportunities. This is something that PGO won’t give you – the native code compiler will have to be defensive and compile everything, not just what it measured on a few runs of test cases. In the JIT’s case, when an assumption is violated, it falls back to the interpreter and recompiles with the new knowledge of the change and thus includes more code than before. The speed advantages of the JIT tend not to be seen on comparison sites like Debian’s language shootout because they don’t exclude start up time and rarely run the code a sufficient number of times to trigger the JIT’s compilation (10,000 method calls by default) to become hot. It’s why the JVM world has tools like JMH to do micro benchmarking. Finally in the Graal case, it’s actually possible to use the Graal compiler as the hotspot replacement so you can see the difference in speed and behaviour between the two. Graal has some nice wins but also some disadvantages; it’s good at fixing some of Scales’s generated code which is why Twitter are big fans, but on regular Java code the advantages are not as pronounced. The main benefit to Graal is the reduction in startup time, not execution speed at runtime. For long running servers you are better off with the JVM’s JIT for performance; for short start up times (like AWS Lambda) you could be better off with jaotc or Graal.
      - pjmlp 6y ago
        And if using a recent Java version (meaning not 8), that JIT code is cached between executions and can even take PGO data into account. There are a couple of talks from the .NET team regarding the same issue, and how they are planning that for full support of all .NET features, the way forward is a mix of AOT/JIT. Android team also learned the hard way that AOT only wasn't as good idea as they thought, hence why ART now does all combinations, interpreted, JIT and AOT with PGO and code cache.
    - moonchild 6y ago
      It's not very easy to compare java's performance with that of other compiled languages, because of the GC. The closest native analogue is go, which is much slower than java, although it's not quite a fair comparison since go uses a concurrent GC by default and java does not. Java is quite fast for what it does, and I don't expect any runtime to make it significantly faster (aside the fact that java isn't slow, and its performance problems are memory usage and lack of value types, which native vs. JIT has no impact on).
      - smabie 6y ago
        Languages like Ocaml and Haskell are both around Java speed, though. And even though both languages have more primitive GCs than Java, in practice, they tend to use less memory and have lower latency. I can only think of one situation when using Ocaml that I had to think about the GC (I was allocated huge floating point arrays), while I can't even count the number of times I had to deal with a runaway heap or unacceptably long pauses. The last JVM version I've really used was 7, though. Perhaps things have gotten better?
        jerven 6y ago
        Yes, things have gotten a lot better. G1GC is the default now and we have free options like ZGC and ShenandoahGC for low latency options. Of course there are the IBM options and Azul as well. Scalar replacement got better, and with Graal partial evaluation gives reduced heap allocation rates. Which can have big impacts. Future is even more bright with inline (value) types going towards even less allocations and better memory layouts.
        grashalm 6y ago
        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.
        jerven 6y ago
    - pjmlp 6y ago
      AOT compilation doesn't make good use of PGO data (you need a very good test data set) and there is zero chance of inlining across dynamic libraries. What most developers want is not having to pay for their tools, hence why so much love for GraalVM community edition. Some form of AOT compilation has been part of commercial JDKs since early 2000's. In fact, the JIT cache that is now also available for free on OpenJDK traces back to J/Rockit and similarly the JIT code caches now available on OpenJ9 go all the way back to WebSphere Real Time JVM. Also this is another point, by holding on to Java 8, those JIT caches are not available to those that only want the free JDK variants. However it is a warm feeling that despite the critic, here is a project that they have kept aliven from Sun Labs (aka MaximeVM) and not only have brought it to production, they have a long term roadmap to replace C2 with it (Project Metropolis).
      - geodel 6y ago
        > What most developers want is not having to pay for their tools, hence why so much love for GraalVM community edition. Well I agree that developers do not want to pay in general. But Graal VM CE/EE are firmly in enterprise domain, so companies have to take a call on Graal.
        pjmlp 6y ago
        Graal VM CE is free beer, hence the attention it is getting now.
    - thu2111 6y ago
      It's not like people are slinging jars over the network between linux and windows That happens all the time. Examples: - Anyone using IDE plugins to IntelliJ, PyCharm, WebStorm or any other developer IDE - Any team where developers are running a mix of operating systems but work on a shared Java codebase - Any place developers pull in Java dependencies from Maven Central/JCenter and then use them in an Android app
    - hrgiger 6y ago
      Debugging native image would be well utilized as well
  - geodel 6y ago
    Indeed. And when documents say "Unless low memory usage is top requirement just use regular JDK for better performance." It does not give much confidence in native solution.
    - topspin 6y ago
      Given Java's outrageous memory usage I think this is pretty compelling benefit. It is not easy to provision resources for Java applications relative to just about everything else.
- gentleman11 6y ago
  Does java come with the tools you need to manually manage your memory to avoid using the garbage collector? In unity with c#, the garbage collector is a major problem that is annoying to work around
  - zelly 6y ago
    There are alt garbage collectors you can plug in or write yourself. https://openjdk.java.net/jeps/304 https://openjdk.java.net/jeps/304
    - entha_saava 6y ago
      That's not what they are asking for. Well there is epsilon GC but rather than writing java that doesn't allocate, I'd rather write C++ or Go. This is the problem with Java ecosystem. Horribly reinventing simpler things in complex ways, from frameworks to build systems, and selling them as next big thing ™.
      - pjmlp 6y ago
        Then you have either the pleasure to win the lottery and be part of the 70% statistic, or do tricks with 1GB memory allocations to force the GC to work, choices.
        zelly 6y ago
        What 70% statistic?
        pjmlp 6y ago
        These 70% https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
- imtringued 6y ago
  You still have a GC and no value types.
  - fotad 6y ago
    Value type is overrated, lots of game engines choose C# because of value type, any game in C# has good performance or memory usage? Unity games are memory hog...
    - pjmlp 6y ago
      Somehow I think they would still be a memory hog if written in C, better not mix the capabilities of the tooling with the skills of those that use them.
      - fotad 6y ago
        Any real world application to demonstrate those skills instead of empty words?
        pjmlp 6y ago
        Yes, but it is up to you to find out, my words are justified by my cv and customer relationships.
soonnow 6y ago
In case you are wondering, like me, what's the point here is some quote from the linked release "The difference for the user is minimal, but for maintainability the upstream alignment with both OpenJDK 11 and GraalVM is critical. It means that Red Hat can offer better support to customers since we have skilled engineers working within the OpenJDK and GraalVM community." So basically RedHat is building this so they have a stable basleline for their Enterprise releases.
- BossingAround 6y ago
  > So basically RedHat is building this so they have a stable basleline for their Enterprise releases. Can you tell me what Red Hat is not building for their enterprise releases?
ShroudedNight 6y ago
I've been out of the loop on the AoT side of Java for a while now. How do these systems handle dynamic class-loading / code generation and things like hot patching?
- darksaints 6y ago
  They don't. They explicitly refuse to compile an app that takes advantage of things that can't statically be determined to be available at compile time. There are a few exceptions, but it is best not to rely on them.
  - tannhaeuser 6y ago
    Given the reliance of most, if not all, major Java apps on reflection, factory patterns, type parameters/generics, and other dynamisms a la Spring (which had been practiced and preached for the longest time), I'd expect most apps won't benefit from AOT compilation then.
    - erik_seaberg 6y ago
      At least you'd still have AspectJ, because it can instrument bytecode before the AOT compiler sees it. Replacing Spring with Dagger would let you codegen your DI, but in 2020 you need a really good reason to blow that much eng work to improve your startup time.
      - pjmlp 6y ago
        One of the things that those sticking to Java 8 are missing out are the JIT caches that are now part of all major implementations, as those features were integrated into the FOSS variants from the commercial products.
    - ebruchez 6y ago
      > type parameters/generics Those are purely compile-time constructs.
    - 6y ago
pabs3 6y ago
Hmm, I wonder what changes are in the Mandrel fork of GraalVM.
geodel 6y ago
After playing with Java native stuff, one thing has become clear to me that is not general purpose technology where one can take existing Java application and make it native. It will not work even for apps that one write while choosing any library from vast Java ecosystem. Framework vendors are betting on fact that most Java apps are HTTP/ORM/JSON plus metrics and security etc. So if framework provide transitive closure of these libraries and provide configuration to compile native, it will work. For my purpose it does not work because I have many more dependencies which do not fit in above framework. Also I prefer to write my code directly with JDK and external libraries without any of these framework.
- WatchDog 6y ago
  Simple applications that don't use reflection are pretty easy to compile with graal native image. You absolutely don't need to use a framework like micronaut. You do however need to understand what libraries you are using, and if/how they use reflection and dynamic class generation.
  - sverhagen 6y ago
    I totally agree with all you said. But as there's different styles and approaches to development, I can say I've mostly worked (and still) on teams where rarely anything we touch works without reflection. Concretely: if you work for a company that has committed and hired to be building Spring (Boot) applications, GraalVM seems like a complete non-starter. To the point of: if you want to deploy serverless applications and GraalVM requires you to write Java code that is so fundamentally different than what you have been doing for so long, why would you even stay with Java, you already lost much of the benefit of it being supposedly "the same language", and you may then just as well write your serverless application in Javascript or Python. Instead of using a far from mainstream solution like GraalVM. I'm even wondering how obvious or subtle the bugs would be if I ever accidentally did something reflective in GraalVM. I found this video very validating for thoughts I already had about how optimizing Java for use in AWS Lambda is not how I want to be programming Java: https://www.youtube.com/watch?v=ddg1u5HLwg8 https://www.youtube.com/watch?v=ddg1u5HLwg8 What he lays out in this video makes me think back to doing my own memory management in C++. There's surely a place for that: high-level application development just ain't that place, in my mind.
fulafel 6y ago
Graal native image is not Java specific, works well for eg Clojure, Scala etc. Does the RH offering also support other Graal supported JVM languages or is it focused on just Java?
person_of_color 6y ago
How does this compare to Jazelle?
mister_hn 6y ago
My question is: if you can code in C++, why should you write C++ on top of GraalVM instead of going native (and faster)?
- zelly 6y ago
  Because Java is much cheaper in terms of development time and HR
  - mister_hn 6y ago
    well I disagree with this. You can waste a lot of time, especially in the debug phase, due to runtime errors not caught at compile time
    - Jataman606 6y ago
      Debugging Java is easier than C++ though.
- pjmlp 6y ago
  Because to code in C++ with the safety of Java, specially in distributed computing scenarios, I have to make people go through this. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://docs.microsoft.com/en-us/cpp/code-quality/?view=vs-2019 https://docs.microsoft.com/en-us/cpp/code-quality/?view=vs-2... And most of the time is a lost battle to force people to change, so it is easier to bring in people that have other culture towards security when plugging software into the network. As for GraalVM support for LLVM, that is mostly for language interoperability purposes.
- hokkos 6y ago
  Because is my case Java is the only language with libraries that implement all the rare needs I have. And because I need to create an application with the smallest memory footprint possible. And in my best attempt at it, I use a Rust Webserver that use a static GraalVM compiled Java library containing all the business code thus eliminating the fat Java http/web libs, so I have a lower exe footprint that translate is smaller memory footprint because executable are loaded in memory at one point.
Animats 6y ago
Wasn't that a feature of GCC Java?
- fulafel 6y ago
  Yep, I remember some Linux distributions even packaged some Java apps compiled to native code using GCJ. There's even vestigal text about shipping native versions of dynamically linkable Java libs in the Debian packaging manual: https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html#policy-gcj-native https://www.debian.org/doc/packaging-manuals/java-policy/ch0... Looks like came around in the early 00's judging by some bug reports in the archives.
  - bzzzt 6y ago
    Yeah. Red Hat even got the Eclipse Java IDE running on it (sort of, it was really buggy and a lot slower than running it on the Sun JDK of the time) After Sun made the JDK GPL it was abandoned very quickly.
anthk 6y ago
If this was implemented by the JPCSP guys it would be a nice counterpart against PPSSPP.
- Hitton 6y ago
  I don't think it would be that much helpful. Emulators usually struggle with speed, not with memory or slow start. The execution speed wasn't measured in the benchmark for good reason. Normally JIT compiled Java performs adaptive optimizations and the execution speed can become faster so it better suits program's real execution profile. You might ask: why not run the program on real life input, save the execution profile and optimize GraalVM output depending on that? Indeed that is possible. But Oracle keeps that part of GraalVM proprietary (in fact selling such improvements are probably the most important part of their GraalVM related business, Oracle is not one of those companies which would make open source software just to be nice). Of course benefit of such optimizations is minimal for containerized server applications that GraalVM is mainly used for, because they are not CPU bound, so for normal users it doesn't really matter. But I think that emulator is one of things where it would actually matter quite a lot.
ksec 6y ago
Reading the article hurts me. The link from RedHat [1] is much better. What is hard to understand is Quarkus. >The Quarkus project was launched in 2019 and provided that evolutionary step needed for Java developers in this new world of Kubernetes and serverless. And on its webpage >A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards. So correct me if I am wrong. Quarkus is an umbrella term for all the "selected" Open Source project that works perfectly on tops of Mandrel / GraalVM and Kubernetes? [1] https://developers.redhat.com/blog/2020/06/05/mandrel-a-community-distribution-of-graalvm-for-the-red-hat-build-of-quarkus/ https://developers.redhat.com/blog/2020/06/05/mandrel-a-comm...
- evacchi 6y ago
  no, it is more than that. It's a framework that performs build-time optimization so that those open source projects bootup faster (e.g. move configuration to build-time) and compile natively (e.g. setup reflective accesses automatically or remove them altogether at run-time). Libraries usually provide a "Quarkus Extension" to do those optimizations.
- sradman 6y ago
  GraalVM has an AoT (ahead-of-time) compiler that links against a “Substrate VM” [1] library. It [still starts as]* bytecode but an executable is generated that has fast startup times and low disk/memory footprint. These properties are important for subsecond Serverless Function spin-up and small container images starting with a minimalist Linux like Alpine. It’s not clear to me if JBoss/Redhat/IBM add anything new to the mix or are simply embracing GraalVM and are trying to make the experience seamless for their customers. [1] https://www.graalvm.org/docs/reference-manual/native-image/ https://www.graalvm.org/docs/reference-manual/native-image/ *update: edited bytecode sentence based on thu2111's comment
  - thu2111 6y ago
    The binary produced by native-image (which uses SubstrateVM) doesn't have any Java bytecode left in it. It's all AOT compiled machine code.
aabbcc1241 6y ago
Are the movement of "native Java / native Scala" be following the language design, and implement a native code generator for the source code / bytecode? Or do they produce the same runtime, but just "more native" implementation? For example, in the traditional java, there are class loader, hot code reload, reflection, garbage collection and rpc supports. If Mandrel or GraalVM does not provide those runtime features, should them still be called Java?
- entha_saava 6y ago
  > class loader, hot reload Difficult in AOT environment and IIRC graal's native-image does a dependency analysis and builds a static binary. There is dlopen() in C, it is possible to dynamically load libraries. The problem is it doesn't play well with modern deployment scenarios compared to static linked binaries. > Reflection, GC These are possible to implement in an AOT language. See Golang.
mastrsushi 6y ago
What makes this better than GCJ? Also if any of these attempts are promising, why are we still using JVM? Writing a native Java compiler seems like a 20+ year old pipe dream.
- maxlybbert 6y ago
  I agree. If Java’s already as fast as native, as people keep claiming, why all the effort to compile to native code? This feels like an old solution to an old problem.
  - fotad 6y ago
    Small size since it does not need JRE, fast launching time, it's good for short living app, something like pay as you go cloud computing...
  - stefs 6y ago
    there is no single "native". you have different compilers for different languages. "native" (i.e. compiled) PHP is still slow. some interpreted languages are insanely fast. in theory, JITed languages could be faster than AOT-compiled languages; in practice that's rarely the case (https://wiki.c2.com/?SufficientlySmartCompiler https://wiki.c2.com/?SufficientlySmartCompiler). hotspot is a just-in-time compiler, i.e. it's still compiled to native code; just not the whole codebase at once and prior to startup, but depending on usage statistics which are gathered during interpreted execution (hot code paths). you can leverage similar statistics in AOT with profile guided optimization. as it stands, native_image starts a lot quicker, needs far less disk space and uses a lot less ram, which is important for CLI- and containerized apps. but it's slightly slower than hotspot, doesn't support dynamic code loading and of course you'll need to recompile your app for different platforms and architectures.
jarym 6y ago
Ok so this is just a re-packaging of GraalVM by RedHat. Which is great for those who want nothing to do with Oracle. But I see this as the only plus - there really are no other differentiators. Keep in mind the relevant license here: GPLv2+CPE (classpath exception) which still applies whether you use Mandrel from RedHat or GraalVM from Oracle. I've used GraalVM and while its a bit fiddly to setup it is great for containerised apps owing to lower memory usage and faster startup - this outweighs (for my use case) the slightly lower throughput vs using regular JVM.
- BossingAround 6y ago
  > Ok so this is just a re-packaging of GraalVM by RedHat I think the implications of this might be much deeper than just a re-spin of Graal. If Red Hat ports all their applications into a native mode, and starts offering native spinoff of EAP, or of their other software, that might be insanely interesting offer... Hell, keycloak is written in Java... It now depends on how strongly will RH push internally for GraalVM adoption.
xvilka 6y ago
I think something that translates to the proper native language is a better goal. Something like c2rust[1] but for Java. There is some PoC[2][3] that can convert basic Java constructs to Rust. It can be taken as a base and improved. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust [2] https://users.rust-lang.org/t/java-to-rust-converter-for-tedious-editing-tasks/6547 https://users.rust-lang.org/t/java-to-rust-converter-for-ted... [3] https://github.com/aschoerk/converter-page https://github.com/aschoerk/converter-page
csense 6y ago
"Supersonic subatomic Java on Red Hat Linux?" Did somebody open a portal to the 1990's?
based2 6y ago
and with https://quarkus.io/ https://quarkus.io/ vmware spring: https://github.com/spring-projects-experimental/spring-graalvm-native https://github.com/spring-projects-experimental/spring-graal...

176 points by shortlived 6y ago

sudosysgen 6y ago

Wow! I think this might be good for Java video games.

heretoo 6y ago
To the best of my knowledge, GraalVM native images are probably slower at runtime, due to the hotspot vm being unavailable.
- smabie 6y ago
  GraalVM native images are slower right now, but there's no reason that has to be the case in the future. I think we all have realized over the last 2 decades that though JIT compilers (like the JVM) should be theoretically faster than a traditional native code compiler, this is rarely (if ever) the case. I wouldn't be surprised if over the next 10 years most JVM code (including Java, Scala, etc) is compiled to native images. It's both clear that Oracle is pushing GraalVM hard and that it's what the consumer wants. If performance was identical, I can't think of a single reason why anyone would choose the regular JDK over GraalVM. It's not like people are slinging jars over the network between linux and windows... hell, now with WSL, that's not even a good reason either.
  - rlp 6y ago
    HotSpot uses a JIT compiler that dynamically recompiles code at runtime to speed up hot code paths. GraalVM native compilation cannot do this, and given the nature of Java's non-reified generics, it's very hard to get equivalent speeds at runtime. Profile-guided optimization is the only hope to recover some of that performance gap, and it's currently only available in GraalVM EE. I'm not sure how the benchmarks compare to HotSpot.
    - smabie 6y ago
      Why would type erasure hurt performance? Certainly expressiveness is curtailed due to Java's generics design (or lack thereof), but I wasn't aware of any performance implications.
      - erik_seaberg 6y ago
        Whenever a generic class method returns an erased type and the caller tries to use it, javac has to insert a runtime check (cast) so the bytecode is typesafe. It also forces boxing of primitive types.
        smabie 6y ago
        But since the type of a function can't change at runtime, why is this necessary?
        erik_seaberg 6y ago
        Because of erasure, there is only one copy of List#get(int), and it returns Object (because there's no other upper bound). The source might say List<String> l = ... String s = l.get(0); which looks typesafe, but to pass the verifier and load, the bytecode has to accept an Object and cast it to String before using it, just like Java programmers had to write by hand before generics (this really sucked). There's not even anything stopping you from putting non-Strings in that List instance via reflection or generic casts (if you ignore the warning) or using a really old javac. You could use a checked collection but that just adds a runtime check during writes that ensures the runtime check during reads will never fail (but the bytecode verifier still won't let you remove it!)
        erik_seaberg 6y ago
        I should have written ArrayList#get. It's possible to write a class that implements List<String> in a typesafe way, but callers using the standard List interface receive an Object and have to downcast.
  - tom_mellior 6y ago
    > I think we all have realized over the last 2 decades that though JIT compilers (like the JVM) should be theoretically faster than a traditional native code compiler, this is rarely (if ever) the case. This is a very broad claim. Do you have data to support it? It would mean comparing production-quality JIT and AOT compilers for the same language, which are hard to find. I'm vaguely aware that LLVM's JIT ambitions never worked out because compile times were too slow, which (IIRC) they tried to mitigate by running fewer optimizations in JIT mode, which meant the quality of the generated code wasn't as good as AOT. I wouldn't call this production quality though, and even so it wouldn't allow you to make your claim as broadly as you are.
  - alblue 6y ago
    Actually the JIT compiler often outperforms native code when hot because the latter doesn’t typically get compiled with PGO and the JIT is effectively PGO at runtime. In addition, the JIT can perform optimisations that a native compiler can’t do, because the JIT can take different decisions if a field is null repeatedly, and thus elide the inclusion of code that supports the non null case leading to potential further optimisations due to dead code elimination and additional inlining opportunities. This is something that PGO won’t give you – the native code compiler will have to be defensive and compile everything, not just what it measured on a few runs of test cases. In the JIT’s case, when an assumption is violated, it falls back to the interpreter and recompiles with the new knowledge of the change and thus includes more code than before. The speed advantages of the JIT tend not to be seen on comparison sites like Debian’s language shootout because they don’t exclude start up time and rarely run the code a sufficient number of times to trigger the JIT’s compilation (10,000 method calls by default) to become hot. It’s why the JVM world has tools like JMH to do micro benchmarking. Finally in the Graal case, it’s actually possible to use the Graal compiler as the hotspot replacement so you can see the difference in speed and behaviour between the two. Graal has some nice wins but also some disadvantages; it’s good at fixing some of Scales’s generated code which is why Twitter are big fans, but on regular Java code the advantages are not as pronounced. The main benefit to Graal is the reduction in startup time, not execution speed at runtime. For long running servers you are better off with the JVM’s JIT for performance; for short start up times (like AWS Lambda) you could be better off with jaotc or Graal.
    - pjmlp 6y ago
      And if using a recent Java version (meaning not 8), that JIT code is cached between executions and can even take PGO data into account. There are a couple of talks from the .NET team regarding the same issue, and how they are planning that for full support of all .NET features, the way forward is a mix of AOT/JIT. Android team also learned the hard way that AOT only wasn't as good idea as they thought, hence why ART now does all combinations, interpreted, JIT and AOT with PGO and code cache.
  - moonchild 6y ago
    It's not very easy to compare java's performance with that of other compiled languages, because of the GC. The closest native analogue is go, which is much slower than java, although it's not quite a fair comparison since go uses a concurrent GC by default and java does not. Java is quite fast for what it does, and I don't expect any runtime to make it significantly faster (aside the fact that java isn't slow, and its performance problems are memory usage and lack of value types, which native vs. JIT has no impact on).
    - smabie 6y ago
      Languages like Ocaml and Haskell are both around Java speed, though. And even though both languages have more primitive GCs than Java, in practice, they tend to use less memory and have lower latency. I can only think of one situation when using Ocaml that I had to think about the GC (I was allocated huge floating point arrays), while I can't even count the number of times I had to deal with a runaway heap or unacceptably long pauses. The last JVM version I've really used was 7, though. Perhaps things have gotten better?
      - jerven 6y ago
        Yes, things have gotten a lot better. G1GC is the default now and we have free options like ZGC and ShenandoahGC for low latency options. Of course there are the IBM options and Azul as well. Scalar replacement got better, and with Graal partial evaluation gives reduced heap allocation rates. Which can have big impacts. Future is even more bright with inline (value) types going towards even less allocations and better memory layouts.
        grashalm 6y ago
        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.
        jerven 6y ago
  - pjmlp 6y ago
    AOT compilation doesn't make good use of PGO data (you need a very good test data set) and there is zero chance of inlining across dynamic libraries. What most developers want is not having to pay for their tools, hence why so much love for GraalVM community edition. Some form of AOT compilation has been part of commercial JDKs since early 2000's. In fact, the JIT cache that is now also available for free on OpenJDK traces back to J/Rockit and similarly the JIT code caches now available on OpenJ9 go all the way back to WebSphere Real Time JVM. Also this is another point, by holding on to Java 8, those JIT caches are not available to those that only want the free JDK variants. However it is a warm feeling that despite the critic, here is a project that they have kept aliven from Sun Labs (aka MaximeVM) and not only have brought it to production, they have a long term roadmap to replace C2 with it (Project Metropolis).
    - geodel 6y ago
      > What most developers want is not having to pay for their tools, hence why so much love for GraalVM community edition. Well I agree that developers do not want to pay in general. But Graal VM CE/EE are firmly in enterprise domain, so companies have to take a call on Graal.
      - pjmlp 6y ago
        Graal VM CE is free beer, hence the attention it is getting now.
  - thu2111 6y ago
    It's not like people are slinging jars over the network between linux and windows That happens all the time. Examples: - Anyone using IDE plugins to IntelliJ, PyCharm, WebStorm or any other developer IDE - Any team where developers are running a mix of operating systems but work on a shared Java codebase - Any place developers pull in Java dependencies from Maven Central/JCenter and then use them in an Android app
  - hrgiger 6y ago
    Debugging native image would be well utilized as well
- geodel 6y ago
  Indeed. And when documents say "Unless low memory usage is top requirement just use regular JDK for better performance." It does not give much confidence in native solution.
  - topspin 6y ago
    Given Java's outrageous memory usage I think this is pretty compelling benefit. It is not easy to provision resources for Java applications relative to just about everything else.
gentleman11 6y ago
Does java come with the tools you need to manually manage your memory to avoid using the garbage collector? In unity with c#, the garbage collector is a major problem that is annoying to work around
- zelly 6y ago
  There are alt garbage collectors you can plug in or write yourself. https://openjdk.java.net/jeps/304 https://openjdk.java.net/jeps/304
  - entha_saava 6y ago
    That's not what they are asking for. Well there is epsilon GC but rather than writing java that doesn't allocate, I'd rather write C++ or Go. This is the problem with Java ecosystem. Horribly reinventing simpler things in complex ways, from frameworks to build systems, and selling them as next big thing ™.
    - pjmlp 6y ago
      Then you have either the pleasure to win the lottery and be part of the 70% statistic, or do tricks with 1GB memory allocations to force the GC to work, choices.
      - zelly 6y ago
        What 70% statistic?
        pjmlp 6y ago
        These 70% https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
imtringued 6y ago
You still have a GC and no value types.
- fotad 6y ago
  Value type is overrated, lots of game engines choose C# because of value type, any game in C# has good performance or memory usage? Unity games are memory hog...
  - pjmlp 6y ago
    Somehow I think they would still be a memory hog if written in C, better not mix the capabilities of the tooling with the skills of those that use them.
    - fotad 6y ago
      Any real world application to demonstrate those skills instead of empty words?
      - pjmlp 6y ago
        Yes, but it is up to you to find out, my words are justified by my cv and customer relationships.

soonnow 6y ago

In case you are wondering, like me, what's the point here is some quote from the linked release "The difference for the user is minimal, but for maintainability the upstream alignment with both OpenJDK 11 and GraalVM is critical. It means that Red Hat can offer better support to customers since we have skilled engineers working within the OpenJDK and GraalVM community." So basically RedHat is building this so they have a stable basleline for their Enterprise releases.

BossingAround 6y ago
> So basically RedHat is building this so they have a stable basleline for their Enterprise releases. Can you tell me what Red Hat is not building for their enterprise releases?

ShroudedNight 6y ago

I've been out of the loop on the AoT side of Java for a while now. How do these systems handle dynamic class-loading / code generation and things like hot patching?

darksaints 6y ago
They don't. They explicitly refuse to compile an app that takes advantage of things that can't statically be determined to be available at compile time. There are a few exceptions, but it is best not to rely on them.
- tannhaeuser 6y ago
  Given the reliance of most, if not all, major Java apps on reflection, factory patterns, type parameters/generics, and other dynamisms a la Spring (which had been practiced and preached for the longest time), I'd expect most apps won't benefit from AOT compilation then.
  - erik_seaberg 6y ago
    At least you'd still have AspectJ, because it can instrument bytecode before the AOT compiler sees it. Replacing Spring with Dagger would let you codegen your DI, but in 2020 you need a really good reason to blow that much eng work to improve your startup time.
    - pjmlp 6y ago
      One of the things that those sticking to Java 8 are missing out are the JIT caches that are now part of all major implementations, as those features were integrated into the FOSS variants from the commercial products.
  - ebruchez 6y ago
    > type parameters/generics Those are purely compile-time constructs.
  - 6y ago

pabs3 6y ago

Hmm, I wonder what changes are in the Mandrel fork of GraalVM.

geodel 6y ago

After playing with Java native stuff, one thing has become clear to me that is not general purpose technology where one can take existing Java application and make it native. It will not work even for apps that one write while choosing any library from vast Java ecosystem. Framework vendors are betting on fact that most Java apps are HTTP/ORM/JSON plus metrics and security etc. So if framework provide transitive closure of these libraries and provide configuration to compile native, it will work. For my purpose it does not work because I have many more dependencies which do not fit in above framework. Also I prefer to write my code directly with JDK and external libraries without any of these framework.

WatchDog 6y ago
Simple applications that don't use reflection are pretty easy to compile with graal native image. You absolutely don't need to use a framework like micronaut. You do however need to understand what libraries you are using, and if/how they use reflection and dynamic class generation.
- sverhagen 6y ago
  I totally agree with all you said. But as there's different styles and approaches to development, I can say I've mostly worked (and still) on teams where rarely anything we touch works without reflection. Concretely: if you work for a company that has committed and hired to be building Spring (Boot) applications, GraalVM seems like a complete non-starter. To the point of: if you want to deploy serverless applications and GraalVM requires you to write Java code that is so fundamentally different than what you have been doing for so long, why would you even stay with Java, you already lost much of the benefit of it being supposedly "the same language", and you may then just as well write your serverless application in Javascript or Python. Instead of using a far from mainstream solution like GraalVM. I'm even wondering how obvious or subtle the bugs would be if I ever accidentally did something reflective in GraalVM. I found this video very validating for thoughts I already had about how optimizing Java for use in AWS Lambda is not how I want to be programming Java: https://www.youtube.com/watch?v=ddg1u5HLwg8 https://www.youtube.com/watch?v=ddg1u5HLwg8 What he lays out in this video makes me think back to doing my own memory management in C++. There's surely a place for that: high-level application development just ain't that place, in my mind.

fulafel 6y ago

Graal native image is not Java specific, works well for eg Clojure, Scala etc. Does the RH offering also support other Graal supported JVM languages or is it focused on just Java?

person_of_color 6y ago

How does this compare to Jazelle?

mister_hn 6y ago

My question is: if you can code in C++, why should you write C++ on top of GraalVM instead of going native (and faster)?

zelly 6y ago
Because Java is much cheaper in terms of development time and HR
- mister_hn 6y ago
  well I disagree with this. You can waste a lot of time, especially in the debug phase, due to runtime errors not caught at compile time
  - Jataman606 6y ago
    Debugging Java is easier than C++ though.
pjmlp 6y ago
Because to code in C++ with the safety of Java, specially in distributed computing scenarios, I have to make people go through this. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://docs.microsoft.com/en-us/cpp/code-quality/?view=vs-2019 https://docs.microsoft.com/en-us/cpp/code-quality/?view=vs-2... And most of the time is a lost battle to force people to change, so it is easier to bring in people that have other culture towards security when plugging software into the network. As for GraalVM support for LLVM, that is mostly for language interoperability purposes.
hokkos 6y ago
Because is my case Java is the only language with libraries that implement all the rare needs I have. And because I need to create an application with the smallest memory footprint possible. And in my best attempt at it, I use a Rust Webserver that use a static GraalVM compiled Java library containing all the business code thus eliminating the fat Java http/web libs, so I have a lower exe footprint that translate is smaller memory footprint because executable are loaded in memory at one point.

Animats 6y ago

Wasn't that a feature of GCC Java?

fulafel 6y ago
Yep, I remember some Linux distributions even packaged some Java apps compiled to native code using GCJ. There's even vestigal text about shipping native versions of dynamically linkable Java libs in the Debian packaging manual: https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html#policy-gcj-native https://www.debian.org/doc/packaging-manuals/java-policy/ch0... Looks like came around in the early 00's judging by some bug reports in the archives.
- bzzzt 6y ago
  Yeah. Red Hat even got the Eclipse Java IDE running on it (sort of, it was really buggy and a lot slower than running it on the Sun JDK of the time) After Sun made the JDK GPL it was abandoned very quickly.

anthk 6y ago

If this was implemented by the JPCSP guys it would be a nice counterpart against PPSSPP.

Hitton 6y ago
I don't think it would be that much helpful. Emulators usually struggle with speed, not with memory or slow start. The execution speed wasn't measured in the benchmark for good reason. Normally JIT compiled Java performs adaptive optimizations and the execution speed can become faster so it better suits program's real execution profile. You might ask: why not run the program on real life input, save the execution profile and optimize GraalVM output depending on that? Indeed that is possible. But Oracle keeps that part of GraalVM proprietary (in fact selling such improvements are probably the most important part of their GraalVM related business, Oracle is not one of those companies which would make open source software just to be nice). Of course benefit of such optimizations is minimal for containerized server applications that GraalVM is mainly used for, because they are not CPU bound, so for normal users it doesn't really matter. But I think that emulator is one of things where it would actually matter quite a lot.

ksec 6y ago

Reading the article hurts me. The link from RedHat [1] is much better. What is hard to understand is Quarkus. >The Quarkus project was launched in 2019 and provided that evolutionary step needed for Java developers in this new world of Kubernetes and serverless. And on its webpage >A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards. So correct me if I am wrong. Quarkus is an umbrella term for all the "selected" Open Source project that works perfectly on tops of Mandrel / GraalVM and Kubernetes? [1] https://developers.redhat.com/blog/2020/06/05/mandrel-a-community-distribution-of-graalvm-for-the-red-hat-build-of-quarkus/ https://developers.redhat.com/blog/2020/06/05/mandrel-a-comm...

evacchi 6y ago
no, it is more than that. It's a framework that performs build-time optimization so that those open source projects bootup faster (e.g. move configuration to build-time) and compile natively (e.g. setup reflective accesses automatically or remove them altogether at run-time). Libraries usually provide a "Quarkus Extension" to do those optimizations.
sradman 6y ago
GraalVM has an AoT (ahead-of-time) compiler that links against a “Substrate VM” [1] library. It [still starts as]* bytecode but an executable is generated that has fast startup times and low disk/memory footprint. These properties are important for subsecond Serverless Function spin-up and small container images starting with a minimalist Linux like Alpine. It’s not clear to me if JBoss/Redhat/IBM add anything new to the mix or are simply embracing GraalVM and are trying to make the experience seamless for their customers. [1] https://www.graalvm.org/docs/reference-manual/native-image/ https://www.graalvm.org/docs/reference-manual/native-image/ *update: edited bytecode sentence based on thu2111's comment
- thu2111 6y ago
  The binary produced by native-image (which uses SubstrateVM) doesn't have any Java bytecode left in it. It's all AOT compiled machine code.

aabbcc1241 6y ago

Are the movement of "native Java / native Scala" be following the language design, and implement a native code generator for the source code / bytecode? Or do they produce the same runtime, but just "more native" implementation? For example, in the traditional java, there are class loader, hot code reload, reflection, garbage collection and rpc supports. If Mandrel or GraalVM does not provide those runtime features, should them still be called Java?

entha_saava 6y ago
> class loader, hot reload Difficult in AOT environment and IIRC graal's native-image does a dependency analysis and builds a static binary. There is dlopen() in C, it is possible to dynamically load libraries. The problem is it doesn't play well with modern deployment scenarios compared to static linked binaries. > Reflection, GC These are possible to implement in an AOT language. See Golang.

mastrsushi 6y ago

What makes this better than GCJ? Also if any of these attempts are promising, why are we still using JVM? Writing a native Java compiler seems like a 20+ year old pipe dream.

maxlybbert 6y ago
I agree. If Java’s already as fast as native, as people keep claiming, why all the effort to compile to native code? This feels like an old solution to an old problem.
- fotad 6y ago
  Small size since it does not need JRE, fast launching time, it's good for short living app, something like pay as you go cloud computing...
- stefs 6y ago
  there is no single "native". you have different compilers for different languages. "native" (i.e. compiled) PHP is still slow. some interpreted languages are insanely fast. in theory, JITed languages could be faster than AOT-compiled languages; in practice that's rarely the case (https://wiki.c2.com/?SufficientlySmartCompiler https://wiki.c2.com/?SufficientlySmartCompiler). hotspot is a just-in-time compiler, i.e. it's still compiled to native code; just not the whole codebase at once and prior to startup, but depending on usage statistics which are gathered during interpreted execution (hot code paths). you can leverage similar statistics in AOT with profile guided optimization. as it stands, native_image starts a lot quicker, needs far less disk space and uses a lot less ram, which is important for CLI- and containerized apps. but it's slightly slower than hotspot, doesn't support dynamic code loading and of course you'll need to recompile your app for different platforms and architectures.

jarym 6y ago

Ok so this is just a re-packaging of GraalVM by RedHat. Which is great for those who want nothing to do with Oracle. But I see this as the only plus - there really are no other differentiators. Keep in mind the relevant license here: GPLv2+CPE (classpath exception) which still applies whether you use Mandrel from RedHat or GraalVM from Oracle. I've used GraalVM and while its a bit fiddly to setup it is great for containerised apps owing to lower memory usage and faster startup - this outweighs (for my use case) the slightly lower throughput vs using regular JVM.

BossingAround 6y ago
> Ok so this is just a re-packaging of GraalVM by RedHat I think the implications of this might be much deeper than just a re-spin of Graal. If Red Hat ports all their applications into a native mode, and starts offering native spinoff of EAP, or of their other software, that might be insanely interesting offer... Hell, keycloak is written in Java... It now depends on how strongly will RH push internally for GraalVM adoption.

xvilka 6y ago

I think something that translates to the proper native language is a better goal. Something like c2rust[1] but for Java. There is some PoC[2][3] that can convert basic Java constructs to Rust. It can be taken as a base and improved. [1] https://github.com/immunant/c2rust https://github.com/immunant/c2rust [2] https://users.rust-lang.org/t/java-to-rust-converter-for-tedious-editing-tasks/6547 https://users.rust-lang.org/t/java-to-rust-converter-for-ted... [3] https://github.com/aschoerk/converter-page https://github.com/aschoerk/converter-page

csense 6y ago

"Supersonic subatomic Java on Red Hat Linux?" Did somebody open a portal to the 1990's?

based2 6y ago

and with https://quarkus.io/ https://quarkus.io/ vmware spring: https://github.com/spring-projects-experimental/spring-graalvm-native https://github.com/spring-projects-experimental/spring-graal...