GCJ - reducing executable sizes

GCJ - reducing executable sizes

[Sal]

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?)
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?
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!?

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

Re: GCJ - reducing executable sizes

[Marco Trudel]

Sal wrote:
> 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 
reimplemented).
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
Marco

> 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