gcj executable size reduction?

[Per Bothner <per at bothner dot com>]

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

One thing that seems worth trying is an option to eliminate reflection 
data.  More likely we'd only keep the minimal reflection data 
correspondin to JDK 1.0 (i.e. cast, instanceof, getClass, forName). 
include the reflection data.  This would most easily be a configure 
option, since otherwise it would be difficult to remove the reflection 
data from libgcj.  However, another solution would be to tell the
linker to drop reflection data, which might not be too difficult if it 
is in specific named sections.

Would this break the new ABI?  That's OK as long as we keep the old ABI 
as an option, I think.  But interface tables may be an issue.

I'm also interested in redesining the reflection data to take up less 
space (and need less relocation on shared library loading), but that 
seems like a big difficult project.

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

Comments?  Where should I start?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/