gcj executable size reduction?

[Boehm, Hans]

There's a related problem, which is on my to-do list for the garbage collector.
It appears that at least for X86 Linux, exception range tables end up in
a writable data segment.  This means the collector scans them for pointers.
The net effect seems to be a significantly larger heap size to compensate for
the scanning time.

If gcj supplied precise root information to the collector, this would no longer
matter for gcj.  But that hasn't happened yet, and has some negative consequences.
If there were a way to identify exception range tables (and reflection information),
I think the runtime footprint of gcj applications would decrease appreciably, even
without reduced functionality.  Plus C++ clients of the collector would also benefit
substantially.

I've only looked at this very briefly.  But it appears this needs some support
in the linker and/or startup code.  There isn't currently a way to identify the
stuff.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Per Bothner
> Sent: Thursday, April 15, 2004 8:36 AM
> To: java@gcc.gnu.org
> Subject: gcj executable size reduction?
> 
> 
> 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/
>