Hybrids Combine GNU Classpath and OpenJDK (InfoQ) [LWN.net]

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 24, 2007 5:22 UTC (Sun) by daney (subscriber, #24551) [Link]

The reality of the situation is that the engineering resources Red Hat dedicated to development of GCJ are going to be devoting less effort to its development and upkeep.

I too hope that GCJ remains viable. But those that find it useful will have to dedicate effort towards maintaining it.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 25, 2007 8:09 UTC (Mon) by irios (guest, #19838) [Link]

I don't have a wide experience on this subject, but in my system, Eclipse-GCJ has always been TREMENDOUSLY slower in startup than non-GCJ eclipse.

It appears to be evident that there should be some advantages for statically-compiled Java, but then the advantages don't really seem to materialize, or GCJ is not good enough to make them visible. And with less effort dedicated to it, it looks less likely that it will ever be.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 25, 2007 10:59 UTC (Mon) by khim (subscriber, #9252) [Link]

It appears to be evident that there should be some advantages for statically-compiled Java

There are.

but then the advantages don't really seem to materialize

To see the advantages you must use statically-compiled Java. And you are not using it with Eclipse-GCJ. Eclipse does a lot of things dynamically so no wonder Eclipse-GCJ is slow.

Actually difference between statically compiled Java and JIT-compiled Java looks like difference between traveling by car and traveling by airplane: with GCJ you have fast startup and fast maneuverability, HostSpot often gives bigger cruising speed. If your programs works second or less GCJ will usually win, if your program works for 3-5 seconds or more - HostSpot will win. Eclipse is very bad style of program to use with GCJ. Short programs or programs with a lot of C/C++ fragments can win a lot, big pure Java programs are better with HotSpot.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 25, 2007 14:25 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]

There is another very large advantage, namely a very large reduction in memory usage. With HotSpot, you need one copy of every bit of compiled code for every running process. With statically compiled code, you can use share the memory pages for a specific shared library between all running processes.

It is theoretically possible to create a static/jit-hybrid which statically compiles most code and puts it in shared memory, but as far as I know, no Java runtime actually does this. With gcj, you pretty much get this functionality for free.

So long as you are running one or two java applications, especially on a server, this is not a problem. But if you want to implement a large part of your desktop, say a few dozens of gui processes, in Java, this will save you hundreds of megabytes, since a modern widget set alone will eat a few megabytes of memory.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 25, 2007 22:43 UTC (Mon) by zlynx (subscriber, #2285) [Link]

The other way to manage running lots of Java applications is to run them all inside the same VM. Each Java application is a class, and can be run as such.

Then, all these application classes can share the same toolkit classes and utility classes inside the VM.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 25, 2007 23:19 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]

By doing so, you give away a huge amount of security. You lose the process boundary as a means for isolating different programs and replace it with the sandbox security model of the host VM. The former is very simple, well researched, has hardware support to minimize the impact of security breaches and has well understood semantics. The latter is complex, new and so fine grained and complex that it's very hard to resolve all corner cases without huge amounts of security issues. It also needs to disable hardware security assistance like the NX bit. It is not a tradeoff I would like to make in any of my systems.

Make no mistake, having a sandbox in addition to separate process spaces is a definite improvement in security, but using it to _replace_ process spaces would in my opinion be a disaster.

You also give up on os level enforcement of memory limits and other kinds of resource usage, lose the possibility of using common system tools like kill, top and ps to handle your processes and so on and so forth. In the end, you will need two versions of each and every system tool, or need to retrofit all current tools to pretend that java thread groups in the master java process live in the same world as processes.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 26, 2007 3:14 UTC (Tue) by Sutoka (guest, #43890) [Link]

Don't forget that if somehow one of the Java applications would cause the
VM to crash/freeze, it will take ALL of the Java apps running on the VM
with it instead of just that single app.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jun 27, 2007 19:56 UTC (Wed) by linuxrocks123 (guest, #34648) [Link]

> There is a need for a static Java compiler, even though the statically
compiled code will probably be never as fast as HotSpot.

You're convinced of that? I'm not.

The virtual machine proponents still have a lot to prove imo. Sure, I can
see how run-time profiling can help with cases where static heuristics
fall down, but you can get that run-time profiling information once with a
profiler and then feed it back into a static compiler as extra information
for optimization ... and then the static compiler can take almost forever
to do its job, while every second of compile-time is another second of
runtime for a JIT compiler! If proper resources were put into GCJ, I
could easily see it beating HotSpot. Heck, I could see statically
compiled Java code that allocates everything on the stack and does not use
objects equaling the performance of C.

Hybrids Combine GNU Classpath and OpenJDK (InfoQ)

Posted Jul 31, 2007 5:43 UTC (Tue) by massimiliano (subscriber, #3048) [Link]

Usual disclaimer: I work in the Mono JIT. So I am biased, because I like JITs, but I also have some experience on the subject.

While, on one hand, I would "instinctively" think of static compilation as absolutely better, the difference is often lost in the noise, and other advantages of using a JIT (even just better cache locality of the code!) often rise above the noise level.

Consider this: both the MS .NET VM (the CLR) and Mono have a way to statically compile the applications instead of using the JIT, and in both cases the static compiler is (for various implementation reasons) the JIT engine itself, working AOT (Ahead Of Time).
Now, the funny fact: in both cases, it is really hard for the static complied apps to beat the JITted ones! In Mono we had to work very hard to bring the performance of statically compiled code to a reasonable (not shameful) level... and I ended up discovering that the MS team had exactly the same issues, and that even on the MS CLR AOT is barely useful.

There are various technical reasons for this, but the simple rule is that usually (as reported in previous posts) the benefits of AOT are evident in very short lived processes, but get lost in the noise otherwise.

Mind you, this does not mean that a JIT is always better than a static compiler! It just means that the real world is more complex than what we initially think :-)