This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stripping libgcj.so.4


On Sunday, Sep 21, 2003, at 17:04 Pacific/Auckland, Erik Poupaert wrote:

I was wondering, after stripping libgcj.so, its footprint went from around 40 Mb to
around 8 Mb:


libgcj.so.4.0.0		       39 833 506	
libgcj-stripped.so.4.0.0 	8 125 908

In order to improve startup times and memory footprint, would stripping libgcj affect
the ability of an executable to produce stacktraces or so? Or would there by other
side effects?

Stripping should have very little, if any, impact on memory footprint and startup time as the pages containing the debug sections will not normally be touched. The only exception is exceptions - when libgcj calls addr2line to get line numbers for stack traces, it will read parts of the debug info. This wont cause the memory footprint of your Java application itself to rise, but will effect the overall resident memory on your machine.


All you should lose by stripping is the line number and source file name on stack traces. You should still get the class & method name for each entry in the stack trace.

There's actually a lot of redundancy in the debug info - much of the same information is duplicated between the debug info and gcj's class reflection data. One day, it might be nice to teach GDB about the reflection data as we could reduce the binary size a lot while preserving debug-ability.

Regards

Bryce.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]