GCJ - reducing executable sizes
Tue Dec 30 03:47:00 GMT 2008
> First off, I just wanted to say 'thanks' to any of the GCJ devs that
> might be on this list, I find it the *coolest* compiler on the planet
> and have been using it for years on numerous projects. Very
> impressive stuff!
> I've decided to do some hacking on GCJ itself - my goal: to reduce
> executable sizes to be a bit closer to what might come from a
> 'typical' gcc c/c++ executable. Just so that we can make smaller
> binary distributables. (Side note, I am not worried about the runtime
> VM, just precompiling everything) I know that some things might have
> to change in undesirable ways to do this, but I'm hoping command line
> arguments can enable/disable the functionality transparently.
> I wanted to ping the list before I started - as I'm sure many here are
> much better with GCC internals than I:
> 1) I have seen the 'no-vm' flag (or similar), and did try this - it
> reduced executable size significantly but still gives a 'Hello World'
> of something in the order of 1-2MB. Have I done anything incorrectly?
> What is the smallest anyone else has gotten an executable (and what
> flags used?)
Cool, never heard about this one. What is it doing?
> 2) I am perusing/researching the GCJ code base, from snapshot, to try
> and get an idea where some of the bulk is coming, and if it can be
> refined. Can any gurus give some pointers on where some possible
> optimizations can be made?
The following is all about static compilation:
From http://jnc.mtsystems.ch/more_info.html -> FAQ:
Q: Why are the binaries so big?
A: The problem now is, that the Java API classes are heavily
interconnected; a simple "Hello World" application uses the security
manager which uses AWT which uses... Because of this, you will always
have a big part of the classlibrary in your binaries.
Since JNC 0.9, you can exclude parts of the class library if you don't
need them and thus drastically reduce the size of your binaries.
So, JNC (GCJ with some enhancements) allows you to exclude the GUI or
the JCE parts of the class library. I once made an experimental
implementation that creates stubs for all objects in libgcj.a and
therefore allows to exclude all objects. The results were quite
promising. You can find the code in the package ch.mtSystems.gcjStubber
in the Subversion repository of JNC (on sourceforge) if you want to take
a look at it.
Another project that might be interesting for you is on the "done with
GCJ" page. Unfortunately not on the publicly linked one, but in the
Wiki(?) (the public one should have been replaced with it for years
now). Unfortunately I forgot the name of the project, but I think it
essentially removes parts of GCJ in the source code and therefore you
will get a very minimalistic compiler that produces small binaries
(sorry to be not of more help here, but I was never able to find that
wiki page and also lost interest in it since it seems to stay "hidden").
> 3) Any pointers on the best places to RTFM for something like this -
> particularly GCJ internals/architecture, as I would love to be better
> prepared for the undertaking
> 4) I heard a rumor that a GCJ lead developer got headhunted, is it
> true? Is the project still alive and kicking!?
From following the list, my impression is that GCJ kind of died when
OpenJDK was released. IcedTea has then been done to create a completely
free Java implementation, but otherwise, I think work has more or less
been stalled. Please note, this is my subjective impression, I think the
main developers see this differently.
So, with OpenJDK being around now, the only advantage of GCJ is the
native compilation. Considering that GNU Classpath is used as class
library provider (mixed with GCJ proprietary code) and that GNU
Classpath is still kinda buggy or has slow implementations in some
important key libraries, I think interest for the native compilation
part has never gained wide spread. Of course this might also have to do
with the bad support for Windows, making it somehow a Linux only project
what is quite sad.
So to conclude my personal summary of the current GCJ situation, I would
say GCJ is interesting for people wanting to compile something on Linux
and not minding fixing some stuff in GCJ/GNU Classpath themselves...
Because I'm very interested in Java to native compilation but want the
same quality of all libraries as provided in OpenJDK, I worked on a Java
to Eiffel compiler the last 6 months. I now have an experimental
implementation (http://jaftec.origo.ethz.ch/download -> JENC) for
Windows. See the manual for an example usage. It compiles all proivded
Java and required OpenJDK classes without modification to Eiffel and
therefore keeps the quality of the Java code. Even the OpenJDK native
libraries (e.g. java.dll) will be used (except jvm.dll which has been
Since Eiffel will compile to native by default and has support for at
least Windows, Linux and Mac, you have a native compiler with the
quality of OpenJDK.
Hope that helps
> Thanks much in advance for any tips, and thanks again for the great
> work on such a product, I hope I can help contribute back something
> useful soon,
> - Sal
More information about the Java