Java JRE vs GCJ

Question

I have this results from a speed test I wrote in Java:

Java

real        0m20.626s
user        0m20.257s
sys         0m0.244s

GCJ

real        3m10.567s
user        3m5.168s
sys         0m0.676s

So, what is the purpose of GCJ then? With this results I'm sure I'm not going to compile it with GCJ!

I tested this on Linux, are the results in Windows maybe better than that?

This was the code from the application:

public static void main(String[] args) {
    String str = "";
    System.out.println("Start!!!");
    for (long i = 0; i < 5000000L; i++) {
        Math.sqrt((double) i);
        Math.pow((double) i, 2.56);
        long j = i * 745L;
        String string = new String(String.valueOf(i));
        string = string.concat(" kaka pipi"); // "Kaka pipi" is a kind of childly call in Dutch. 
        string = new String(string.toUpperCase());
        if (i % 300 == 0) {
            str = "";
        } else {
            str += Long.toHexString(i);
        }
    }
    System.out.println("Stop!!!");
}

I compiled with GCJ like this:

gcj -c -g -O Main.java
gcj --main=speedtest.Main -o Exec Main.o

And ran like this:

time ./Exec                     // For GCJ
time java -jar SpeedTest.jar    // For Java

Vanzant

Why are you compiling with debugging (-g) enabled? – Pouliot

@Matthew: I found it like that on a forum. But that doesn't change anything to the performance of it, I think. – Vanzant

It would be awesome if the project was re-started and was aimed more at performance like jet. Because the Java language I wonderful but I dislike the necessity of a VM. – Brott

@Youarefunny: Java is impossible without a VM. Even after you compile your classes to a native binary, they still need Java memory management, garbage collection, threading, JNI, and so on. Unless your Java app is within one order of magnitude from "Hello world" in terms of complexity, you cannot transform it automatically into a functionally equivalent C program not sporting all those "overheads". – Dub

Related: #4036038 – Kroeger

"Kaka pipi" sounds like old German to me, dating back to Roman times when they were fighting them off and used to scream it during battle. – Leilanileininger

Answer 1

GCJ is obsolete. It was started a long time ago because people wanted an open-source alternative to the Sun JDK, and it was never particularly good. Now that Sun open-sourced their JDK, there's absolutely no reason to use GCJ (but it still lurks in some Linux distros).

Kamenskuralski

But what about environments without a JVM? iPad, for example? – Carbone

Ah. OK, end of story. Was not aware of that yet. Not that I am jumping for an iPad myself... – Carbone

Doesn't Sun's JDK/JRE require a EULA? That makes it non-free by most distros standards, which is a reason for many not to use it. I believe OpenJDK is intended to be the open replacement. – Quarrier

Yes, OpenJDK is what I meant. (By the way, does anyone understand the difference between OpenJDK and the Sun JDK? Aren't they both built from exactly the same source code?) – Kamenskuralski

@Mike, not yet, since the Sun JDK includes some third-party proprietary code. However, OpenJDK is the focus of future development, and they are trying to get rid of all code that isn't GPL-compatible. – Pouliot

@Egon: The Iphone has Jazelle, although it's not used, and even if it didn't have a JVM, if you can compile arbitrary code, you can compile a JVM....... – Counterrevolution

@Longpoke Except that the JVM MUST be able to compile code AT RUN-TIME for decent performance -- which is not allowed on iOS – Indignity

@MikeBaranczak, Do you mean that javac is now free, free as in speech? – Stephen

Even now there is development of GCJ, so I am not sure if it is obsolete but it does seem to be the popular choice. gcc.gnu.org/gcc-6/criteria.html – Mail

@MikeBaranczak, no they weren't at the time you commented. They had different AWT implementations (Oracle's was faster), and OpenJDK was first to do AES256 without the crypto-export check (since the US exempts OSS from that requirement). – Illuminometer

@Mail There is no evidence of that in your citation. That page is about development of GCC. Not GCJ.. GCJ was pronounced dead by one of its authors in October 2016: tromey.com/blog/?p=911, not having been updated since about 2006, and never having been completed to even Java 1.2 level. – Mattoid

Answer 2

It's not a fair comparison when you do the AOT (Ahead-Of-Time) compile with little optimisation (-O). Try at least -O2.

It's also not as simple as one is faster than the other on a single contrived test. AOT compilation works best in some scenarios. JVMs work better in others, and it also depends heavily on the quality of the JVM. In the real world, ecj is noticeably faster at building OpenJDK when AOT-compiled rather than when running on the JVM. For long-running applications, the JVM is likely to win because it can make use of dynamic optimisations not possible ahead-of-time. ecj suffers because for the short period it's compiling, the JVM is still interpreting code. HotSpot compiles and optimises code when it determines it's worthwhile (a 'hot spot').

BTW, it's the FAQ that's out of date. GCJ supports most of 1.5, certainly enough to build OpenJDK. Without GCJ still 'lurking in some Linux distros', it wouldn't be possible to build OpenJDK in the first place.

Asshur

Answer 3

On x86 and AMD64, Hotspot only uses SSE for floating point, but I see that on x86 gcj doesn't seem to support SSE and uses the much slower 387 instructions:

gcj -O3 -mfpmath=sse --main=Bench Bench.java -o Bench
jc1: warning: SSE instruction set disabled, using 387 arithmetics
/tmp/ccRyR50H.i:1: warning: SSE instruction set disabled, using 387 arithmetics

so that could explain the speed difference.

Note that when GCC does use SSE, it greatly outperforms Hotspot on floating point, since GCC generates SIMD instructions while Hotspot only uses the unpacked SSE arithmetic.

Guffaw

Answer 4

OpenJDK's native Java compiler is, itself, written in Java; as a consequence, you need a working previous version of Java in order to build a new version.

If you're starting from scratch on a platform for which no existing JDK binaries are readily available (or if you're working within certain Free Software projects whose charters prohibit the use of proprietary build dependencies), then GCJ (or some of its underlying components) can be one potential solution to the chicken-and-egg problem of getting a working, albeit somewhat inefficient bootstrap Java in place, in order to move on to build the more desirable OpenJDK.

In fact, back when OpenJDK was first announced, significant effort (via the IcedTea project) was spent in fixing up GCJ to get it to the point where it was up to the task.

Sanitarian

Answer 5

"So, what is the purpose of GCJ then?"

Some have pointed that your "benchmark" isn't fair. However, even if it was, I can still see a use for GCJ. Suppose you want to write a kernel in Java. With a JVM, you have to port the VM to a standalone environment, and then you would have to write the low lever code in C. With an AOT compiler, you can work around this issue with some glue code and then can do the low level code in Java too. No need to port the compiler in this case.

Also, we have to separate the technique from the benchmarks. Perhaps the AOT technique can be more powerful than the JIT technique provided that we invest enough development effort in it.

Augustinaaugustine

Answer 6

You have stumbled onto another product of the "Software Freedom at any cost!" line of thinking. GCJ was created to allow compilation and execution of Java code without depending on anything deemed "non-free" by GNU project.

If you value software freedom enough to take a 12x performance hit, then by all means, go for it!

The rest of us will happily use Sun's (er, Oracle's) incredible HotSpot JVM.

See also: The GCJ FAQ: "I have just compiled and benchmarked my Java application and it seems to be running slower than than XXX JIT JVM. Is there anything I can do to make it go faster?"

Also: "It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions." So it's just a bit out of date as well.

Folio

It's not just out of date, it's completely deprecated. OpenJDK is what's in use now. – Quarrier

I never said anything against software Freedom, and I'm glad that OpenJDK exists. I'm sorry if my answer was a bit cynical, I try to use and contribute to free software when I can, but choose realistic solutions when required. – Folio

I'm with you, Mark. I don't see anything uninformed here. What is at issue here is GNU's idea of 'free', not yours or mine or Sun's; also GNU's idea of Java frankly. GCJ & GNU CLASSPATH don't support all of 1.2, let alone all of any subsequent release. In any case the 'freeness' of Sun Java has changed radically since GCJ and GNU CLASSPATH were initiated. – Mattoid

It's COMPLETELY uninformed. GCJ isn't even an effort to replace the JVM/JRE -- it's an effort to do something DIFFERENT: an AOT compiler for java. Even if you weren't aware of that previously, simply reading details of the original post would have made the distinction clear. – Malapropism

As Andrew mentioned above... GCJ is a build dependency for OpenJDK. And acutally that is one of the main points of it's continued existence. Most likely at some point it will be upgraded again as JDK 8 increases feature requirements if I am not mistaken. – Vignola