shriveling libgcj

Sat Nov 10 21:06:00 GMT 2001

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