binary sizes

Wed Feb 18 02:02:00 GMT 2004

So I'm making some headway on stripping unreachable methods using
BCEL... (.java -> .class -> BCEL -> .class -> gcj -> .o). Right now
the major size components of my binary (gcc 3.3.2 -Os, linux/x86,
static libgcj and libgcjgc, dynamic everything else) wind up like
this:
 .text 37%
 .rodata 13%
 .data 26%
 .eh_frame 20%
Question: I assume that eh_frame is DWARF2 stack-unwinding data,
right? Is it really supposed to consume 20% of the binary? Would
switching to sjlj get me back that space (at the price of poorer
try/catch entry performance)?
Another question: does the GNU linker merge indentical read-only
sections on x86? Is GCJ marking all of its Utf8 sections read-only?
Also, I can't really think of much read-write static data that should
be in a gcj binary... especially not 750k worth... what's in .data?
Last question: can anybody think of a quick hack to let me get rid of
reflection metadata? My app doesn't use reflection at all, although I
seem to remember natClass.cc and natClassLoader.cc doing a lot of
reflection (bummer). I'm not using indirect dispatch (yet).
Thanks!
 - a
-- 
In 1845 the Potato Famine decimated Irish agriculture because of lack
of genetic diversity. Over 150 years later, we still haven't learned
this lesson, which is why the plague of Microsoft viruses will
continue for as long as the software monoculture does.