Re: gcj executable size reduction?

[Bryce McKinlay <mckinlay at redhat dot com>]

Per Bothner wrote:

> Reducing the size of (statiuc) gcj executables is a big priority for 
> my client, so I'm ready to spend some time on this issue.  It would be 
> helpful to get a feel for what people are already doing, planning on 
> doing, or have given up on doing!
>
> One thing that seems worth trying is an option to eliminate reflection 
> data. 
>
> Would this break the new ABI?  That's OK as long as we keep the old 
> ABI as an option, I think.  But interface tables may be an issue.


It does - the new ABI requires reflection data since it uses this to 
link classes together at runtime. Yes, you'd have to implement some 
solution for interfaces regardless of which ABI is used, but if you're 
doing a completely static compilation with no runtime loading, then in 
theory you could generate the interface tables at compile time.

> I'm also interested in redesining the reflection data to take up less 
> space (and need less relocation on shared library loading), but that 
> seems like a big difficult project.
>
> Another (complementary) approach is reducing the interdependencies 
> between classes, so a static linker would not link in quite as much 
> junk.    This might be to be a confiuration option, or we could 
> support various "profiles" like J2ME.  Any experience in untangling 
> dependencies?


I know some people (Adam Megacz?) have done work in this area. Using the 
new ABI would make this easier, too, since you would be able to remove 
classes/methods at link time without the linker complaining (see my 
earlier post).

David Daney wrote:

> I think you could break libgcj into several parts.  For the security 
> related parts there would be two versions (the full implementation and 
> the null implementation) that would be selected at either compile time 
> or perhaps compiler build time. 


Although I'm not keen on splitting up libgcj at the .so level, I've 
often thought it might be benefitial to increase libgcj's internal 
modularity. If done well, with the core runtime more cleanly separated 
from the class libraries it would be easy to plug in a "libgcj-lite" 
class library more suited to embedded development.

But please don't even think about putting preprocessor directives in 
.java files to try and create optional dependencies.  That would simply 
become unmaintainable. Seperate sets of class libraries that implement 
different specs, and/or a compiler or high-level tool which can remove 
dependencies you don't need are really the only sane ways to go about 
this ;-)

Andrew Haley wrote:

> This is all very difficult.  What we really need, I suspect, is a few
> well-defined subsets.
>  

They already exist. For example: J2ME CLDC.  This suits embedded 
development nicely, since it does away with things like reflection and 
security, and has very little interdependence between the classes. Of 
course, every embedded device probably has different needs, but this 
kind of thing provides a good base platform.

Regards

Bryce