
RedHat Mandrel Makes Java Native - shortlived
https://www.infoq.com/news/2020/07/mandrel-graalvm/
======
geodel
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.

~~~
AJRF
+1 - I tried using GraalVM for a Clojure(script) + re-frame application
recently and it didn't work, changing back to OpenJDK works fine. It's a shame
because the times were Graal does work, the start-up time is orders of
magnitude faster.

~~~
kimi
What often is not clear is that GrralVM in "native" mode is NOT faster than
JVM mode, because the JVM has a number of tricks up its sleeve for dynamic
optimization based on actual usage patterns. It definitely has faster startup
times, but for a web client/server application this is not so significant.

~~~
imtringued
I personally am more interested in the lower memory usage.

~~~
thu2111
Memory usage is smaller mostly for small apps. Larger apps will see larger
memory usage because the GC and heap layout is a lot weaker.

SVM/native-image has its place, but currently it's optimised for things like
command line apps or servers that people constantly shut down and start up to
try and save on huge AWS costs. Actual runtime throughput and latency will be
far better on regular OpenJDKs, especially the latest ones with much better
garbage collectors.

------
ksec
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-
comm...](https://developers.redhat.com/blog/2020/06/05/mandrel-a-community-
distribution-of-graalvm-for-the-red-hat-build-of-quarkus/)

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

------
soonnow
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
> 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?

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

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

~~~
darksaints
Yeah, it is not going to compile everything. For most Java apps, which were
built in a world where startup time was a known disadvantage of the JVM, they
will probably be better off with a JITed VM anyway. This is more of a new
capability, allowing JVM languages the ability to move into usecases where
they have never shined before. Like CLI apps, for example. I would expect most
usage of AOT compilation will be for new software, not existing software.

That being said, generics and factory patterns aren't a problem for graal at
all. Reflection and dynamic class loading are the biggest offenders.

~~~
MaxBarraclough
How about GUI? Does JavaFX rely on dynamic classloading? (I presume so, given
its XML-driven approach.) If so, would it be possible to refactor it away? Or
perhaps introduce a preprocessing phase of some sort?

~~~
vips7L
Gluon put out substrate which is supposed to do this:

[https://github.com/gluonhq/substrate](https://github.com/gluonhq/substrate)

~~~
MaxBarraclough
Great that this is in the works.

Do you know about its workings?

~~~
vips7L
I do not, other than it's based on GraalVM native image. I just know of its
existence. I believe this is how gluon is pushing crossplatform for iOS since
apple doesn't like the JVM JIT.

------
fulafel
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?

------
xvilka
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-
ted...](https://users.rust-lang.org/t/java-to-rust-converter-for-tedious-
editing-tasks/6547)

[3] [https://github.com/aschoerk/converter-
page](https://github.com/aschoerk/converter-page)

------
Animats
Wasn't that a feature of GCC Java?

~~~
fulafel
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/ch0...](https://www.debian.org/doc/packaging-manuals/java-
policy/ch02.html#policy-gcj-native)

Looks like came around in the early 00's judging by some bug reports in the
archives.

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

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

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

~~~
heretoo
To the best of my knowledge, GraalVM native images are probably slower at
runtime, due to the hotspot vm being unavailable.

~~~
smabie
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
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
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
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
But since the type of a function can't change at runtime, why is this
necessary?

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

------
mister_hn
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
Because Java is much cheaper in terms of development time and HR

~~~
mister_hn
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
Debugging Java is easier than C++ though.

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

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

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

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

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

------
based2
and with [https://quarkus.io/](https://quarkus.io/)

vmware spring: [https://github.com/spring-projects-experimental/spring-
graal...](https://github.com/spring-projects-experimental/spring-graalvm-
native)

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

------
person_of_color
How does this compare to Jazelle?

