binary sizes

[Per Bothner]

Adam Megacz wrote:

> If UTF8 stuff really is in .rodata (I'm using gcj 3.3.2 on linux/x86),
> then UTF8 constants aren't contributing much to my binary size (and
> they'll compress well anyways)... what else could be in that massive
> read-write data segment?

You can see yourself in libjava/java/lang/Class.h (though it could
do with more comments explaining each field).

The data structure are nicely laid out for efficient use, but
we don't really need that often.  It would be better to have a
more compressed pointer-free encoding, which can be expanded
at run-time when reflection is needed.

There is a tradeoff in some case.  For example we could replace
pointers to _Jv_Utf8Const names by short indexes into a name
buffer, but that complicates coalescing equal names from
different compilation units.  That replaces a 32/64-point pointer
plus its relocation info by a shorter (16-bit?) offset, so it's
probably worth it, at least when compiling entire packages or
more into a single .o files.

When you actually need reflection, the compressed data can
be extracted and a java.lang.reflect.{Field,Methods} created,
and used efficiently.

In this module the structs _Jv_Method and _JV_Field would do away.
The JNI jmethodID would be a (java::lang::reflect::Method *).

One possible simple optimization may be to remove the hash and
length fields of _Jv_Utf8Const.  That removes 4 (or 5 because of
padding) bytes per name.  That would hurt performance when
searching for a matching name, but perhaps that doesn't matter,
or can be made to not matter.  (Though note that some pointers
count on the fact that a _Jv_Utf8Const is short-aligned.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/