This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
binary sizes
- From: Andrew Haley <aph at redhat dot com>
- To: Adam Megacz <adam at megacz dot com>
- Cc: java at gcc dot gnu dot org
- Date: Wed, 18 Feb 2004 10:12:48 +0000
- Subject: binary sizes
- References: <E1AtH4K-0001y4-00@megacz.com>
Adam Megacz writes:
>
>
> Question: I assume that eh_frame is DWARF2 stack-unwinding data,
> right? Is it really supposed to consume 20% of the binary?
Yes.
> Would switching to sjlj get me back that space (at the price of
> poorer try/catch entry performance)?
Perhaps, but we're moving to removing the traditional stack chain by
compiling with omit-frame-pointer: once that move is complete, DWARF2
unwinder data will be needed everywhere.
> 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?
I don't know what all this stuff is. Much of it is probably
reflection data, most of which shold be read only.
> 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).
Some of the reflection data is used by the gc. You can remove most of
it, though. You'll have to experiment.
Andrew.