class metadata (was Re: GCJ information)

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Per Bothner wrote:

> Tom Tromey wrote:
>
>> If you're concerned about size, I think there are two really
>> worthwhile things to do that nobody has tried yet:
>>
>> 1. Change the representation of metadata.  For instance, it could be
>> stored compressed and then decompressed during class initialization.
>> Done properly this could also reduce startup time when libgcj is
>> dynamic, by reducing the number of relocs required.  There have been a
>> few discussions of this and related ideas on this list.
>

Have you seen Jakub Jelinek's prelinking work? I havn't tried it yet, 
but suspect it will pretty much nail the libgcj.so startup time issue 
(it sure does for KDE).

> I've done a little thinking about this.  I suggest *not* decompressing
> during initialization, but deferring it until we actually need it,
> for reflection, JNI, or serialization.  


For my binary compatibility patch, they must be decompressed 
before/during class initialization. Also the interpreter needs them, as 
does the interface table layout code (though that could/should be moved 
to compile time for the --no-binary-compatibility case).

Binary compatibility is of course not relevant for a static binary, but 
the same approach (getting rid of static vtables etc) gives us the 
weaker binding that is a prerequisite for including only used classes in 
a static binary. I suspect that being able to get rid of unneeded 
classes will save far more space than compressed metadata!

Other reasons why compressed metadata might be bad:

_Jv_Methods etc are smaller than mangled C++ symbols because the 
compiler/linker merge duplicate constants. Thus the same method name in 
different classes gets merged to the same Utf8Const for example. So, by 
trading mangled symbols for _Jv_Methods, binaries become smaller.

Utf8Consts are true constants, and _Jv_Methods would be constant with 
both prelinking and --no-binary-compatibility. Thus they can be shared 
between different applications when in a shared library. If they were 
generated at runtime from compressed data, that property is lost. (For 
binary compatibility they can not be constant because the index (for 
methods) and offset (for fields) must be set at runtime. But libgcj can 
be built without binary compatibility and still support binary 
compatible binaries)

I'm not entirely opposed to this idea, but I think we need to think 
carefully whether it is really a win, and if so if the effort (and added 
complexity) required to implement it wouldn't be better spent elsewhere.

> The other idea is
>
> typedef java::lang::reflect::Field _Jv_Field;
> typedef java::lang::reflect::Method _Jv_Method.
>
> That way we don't need duplicate data structures. 

Well, a java.lang.reflect.Method is only needed for reflection, so I'm 
not sure thats a win either (hmm... maybe for a JIT written in 
Java...?). It adds a relocation unless you want to set the vtable 
pointer lazily.

Bryce.