gcj executable size reduction?

[Tom Tromey]

Per> Reducing the size of (statiuc) gcj executables is a big priority for
Per> my client, so I'm ready to spend some time on this issue.  It would be
Per> helpful to get a feel for what people are already doing, planning on
Per> doing, or have given up on doing!

Per> Another (complementary) approach is reducing the interdependencies
Per> between classes, so a static linker would not link in quite as much
Per> junk.    This might be to be a confiuration option, or we could
Per> support various "profiles" like J2ME.  Any experience in untangling
Per> dependencies?

On the GUI branch there is a Makefile patch that splits libgcj.so into
several bits.  AWT and Swing drop out pretty cleanly -- only
AWTPermission needs to remain in the core (for SecurityManager).
Other parts drop out a little less cleanly.

I think with the new ABI we should be able to separate things as much
or as little as we like.  Most classes will be linked at runtime, so
if you know a class is unused you should be able to simply omit it.

I suppose this will wreak havoc with static linking.  And there's
still the question of whether the minimal subset of the libraries is
too big.

I don't think the Makefile change from the GUI branch can go in as-is,
but maybe it will serve as a starting point.  I'd like to see Andrew's
ABI patches go in as soon as possible, on a new branch for that
purpose.  Then we can all play with them to find out the ramifications
on executable size (and whatever else).

Perhaps all we need is a tool that takes a .jar and makes a list of
all the core classes you need to link in...?

Do we know how much space the reflection data takes?  I wonder if that
is the biggest problem.  (I have no idea.)

Tom