Re: gcj executable size reduction?

[Dalibor Topic <robilad at kaffe dot org>]

Hi Boris,

Boris Kolar wrote:
> > I've also used jikes in the past, to compile java.lang.Object and let it
> > drag in all the dependencies automatically. It mostly works, as far as I
> > recall. It's a rather quick way to figure out the 'resident size' of
> > your class library.
>
>
> Wouldn't that also include "private" dependancies (dependancies in
> private methods,...)?

Yes.

> I think it wouldn't be that difficult to use reflection to determine
> public+protected dependancies of an object. These "public"
> dependancies can't be removed unless you are willing to sacrifice
> compliance with standards. But I guess removing private dependancies
> would help a lot.

Usually the private methods are used to implement the public ones. For 
example, when several of your public methods need to do A, then 
refactoring A into a private method of its own helps clean up the code.

Doing the jikes thing above, for example, results in a core rt.jar for 
kaffe [1] that's about 600k, whereas the normal rt.jar for kaffe is 
around 3 megs. Of course, chances are that in this 600k there is some 
necessary stuff missing, which is required to run actual programs; like 
localization or character conversion ressources, or classes only loaded 
through reflection.

But it provides a quick starting point for such 'prune down the class 
library to bare necessities' applications for embedded users. It was 
what I used when I added support for class library profiles in kaffe.

cheers,
dalibor topic

[1] Not that kaffe doesn't use the same libraries that gcj uses, so the 
actual results on gcj's class libraries may be different.