stripping libgcj.so.4 -- lightweighting libjava

Sun Sep 21 10:49:00 GMT 2003

> 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.

At this point in time, GDB-debugability doesn't necessarily seem to be a widely
shared concern (quite a few people resort to the one or the other form of logging
anyway). In my impression, real and perceived memory footprint, startup time, and
executable size seems to bother people more (well, it does me...).
I've had a close look at libjava/configure.in. The first thing that struck me is the
fact that it would harm few people to remove quite a few dependencies. These
dependencies could still be linked seperately, outside libgcj, for the ones who
need it, while offering an attractive, lightweight implementation to the vast
majority of current and prospective users.
GCJ won't be an immediate or runaway success anyway in the typical bytecode
scenarios: applets, servlets, beans, enterprise beans,... Keeping in mind what the
typical uses are, and where it actually could be successful: GUIs with SWT,
commandline tools, xinetd programs, possibly cgi-scripts, ..., we can see that the
excess fat in libjava only tends to impede GCJ's success instead of contributing to
it:
----------------------------------------------
REALLY NEEDED
----------------------------------------------
core_java_source_files
ordinary_java_source_files
c_source_files
----------------------------------------------
EXCESS FAT
----------------------------------------------
lib_org_w3c_dom_la_SOURCES:	optional for the (few) afficionados?
				no need to stuff libgcj with it?
lib_org_xml_sax_la_SOURCES:	optional for the (few) afficionados?
				no need to stuff libgcj with it?
lib_gnu_awt_xlib_la_SOURCES:	doesn't even really work. Why not outside libjava?
awt_java_source_files:		doesn't even really work. Why not outside libjava?
rmi_java_source_files:		the afficionados tend to use other implementations anyway
javax_source_files:		never seen anybody using this
x_java_source_files		never seen anybody using this
gnu/java/locale/LocaleInformation_af_??.java: why not link only
				the one you actually need?
gnu/java/nio:			why not seperate for the afficionados?
java/nio:			why not seperate for the afficionados?
----------------------------------------------
NOT USEFUL IN ANY WAY FOR TYPICAL GCJ USE
----------------------------------------------
java/security
gnu/java/security
Is it possible to optionalize/IFDEF every reference to this namespace?
By removing excess fat outside the core, and stripping the resulting libgcj.so, what
footprint and performance gains can be achieved already?
I am currently trying to do the excercise with brute force (taking out stuff the
silly way). I feel that a functional libgcj.so should be possible in less than 2 MB
(instead of a staggering 40 MB)?