Re: [Patch] Add option to reduce amount of reflection data to gcj...

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Here is my patch to optionally reduce the amount of reflection data 
 > generated by gcj.  When applied to libgcj on i686 I see about 5% 
 > reduction in memory image size.
 > 
 >     text    data     bss     dec     hex filename
 > 18937435        3615244  260644 22813323        15c1a8b 
 > /home/daney/gccsvn/native_clean/i686-pc-linux-gnu/libjava/.libs/libgcj.so.7.0.0
 > 18284867        3254316  260644 21799827        14ca393 libgcj.so.7.0.0
 > 
 > On my GCC-3.4.3/mipsel-linux port of the patch when used in conjunction 
 > with static linking I am getting about 12-15% savings on a fairly large 
 > (1000 classes) application.
 > 
 > There are of course several caveats:  By eliminating a lot of reflection 
 > meta-data, a lot of reflection operations will fail.  No big surprize 
 > there.  JNI and the binary compatibility ABI depend on complete 
 > reflection meta-data, so they cannot be used in conjunction with reduced 
 > reflection meta-data.  The byte code interpereter, and the gij program 
 > work on some, but not all, programs with reduced reflection meta-data.
 > 
 > Tested on i686-pc-linux-gnu (FC3).
 > 
 > When -freflection-data= is not specified, no regressions with full 
 > bootstrap of all default languages.  I generated assembly language for a 
 > 122 class package with and without the patch and the *only* differences 
 > were the movement of the vtables from after to before the reflection 
 > data.  This is to be expected from the patch.  Adding 
 > -freflection-data=reduced to my libgcj.spec.in, resulted in many (about 
 > 180) failures in the libgcj testsuite.  These were in some, but not all, 
 > gij compilation tests as well as JNI, BC and some specific reflection 
 > tests.  I am considering this a pass as some things are not expected to 
 > work with the -freflection-data=reduced option enabled.
 > 
 > OK to commit?

I don't think the -freflection-data=none option should be there in its
current form, since it breaks so much.  Perhaps this option could be
enhanced so that we don't silently generate incorrect code.  We should
report an error instead.

If it's incompatible with -findirect-dispatch, it should error if
these options are combined on the command line.

Andrew.