Re: shriveling libgcj

[Jeff Sturm <jsturm at one-point dot com>]

On 10 Nov 2001, Tom Tromey wrote:
> I believe the biggest wins in terms of shrinking executable size would
> come from not from disabling particular files or even Java packages
> but from implementing "section GC".  This is what I concluded after
> spending a few days looking into the size issue a few months ago.

No doubt, it'd be nice to have -fvtable-gc working, even though it seems
the potential benefit is quite limited; a quick check reveals that the
.text section only makes up around 29% of a stripped libgcj.so on my
alpha-linux box.  I'd suppose the fraction of .text in a static build
would be somewhat larger with the absense of relocation info.

Shrinking class metadata would help reduce both the initialized data and
relocation sections, which appear to be a larger portion of the
executable.  Also this would work fine together with -fvtable-gc.

I also like Bryce's idea of fixing -fassume-compiled.  Many classes in a
static build are likely never even initialized; these are all wasted
space.  Runtime feedback could be useful.  It's easy to hack libgcj to
dump a list of classes that are initialized during execution... this list
could be used in turn to link a minimal set of compiled classes into a
static build.

Below is the breakdown of my libgcj.so, with the smallest sections omitted
for brevity.  Unmapped sections (e.g. .symtab) are not shown.  I'm a bit
surprised that well under half of the overall text segment is actual
machine code.

.hash                         102144     1%
.dynsym                       245160     4%
.dynstr                       468436     8%
.rela.data                   1247088    22%
.rela.got                      55200     1%
.text                        1625568    29%
.rodata                       368605     6%
.data                         732128    13%
.eh_frame                     332136     6%

Jeff