Re: Binary size of statically linked java application

[Marco Trudel <mtrudel at gmx dot ch>]

Lehner, Michael wrote:
> > -----Original Message-----
> > From: Marco Trudel [mailto:mtrudel@gmx.ch]
> > Sent: Wednesday, November 29, 2006 2:41 PM
> > To: Lehner, Michael
> > Cc: java@gcc.gnu.org
> > Subject: Re: Binary size of statically linked java application
> >
> > Lehner, Michael wrote:
> > > [Lehner, Michael]
> > > I first tried to get away from AWT, this was very easy. I had to
> write 3
> > > classes and 4 functions I think.
> > Then you did something wrong and your executable is probably only
> about
> > 50kb smaller. It's not done by removing awt.o. There are about 30
> > objects for awt...
> [Lehner, Michael] 
> I removed everything with awt in the filename and my executable reduced
> its size from 9MB to 6,2MB. And Swing I didn't find in the map-file, the
> linker generated.
> How can I find out what objects are also for awt, if the name doesn't
> indicate this?

Look what's in them with objdump or nm.


> > > I think it would be helpful if there would be a libgcj.a, that means
> a
> > > classpath, without any implementation, but only empty functions.
> > I don't know what you mean by this...
>
> [Lehner, Michael] 
> I mean a libgcj.a without any functional code, only filled with stubs
> but in the next lines you show me another way.

No, that wouldn't make much sense. You too have to consider the 
automatic pulling in mechanism used by archives (the linker). You can't 
do that easily another way...


> > > When
> > > minimizing de code you would only have to remove an original file
> from
> > > it and use instead the one with the same name from the other library
> > > with only the function names inside.
> > They still would have to be precompiled. So the only difference is
> that
> > all objects are now in an archive and you suggest to put them into a
> > directory. Doesn't change that much (unless I understand you wrong).
> > Anyway, you can keep the original libgcj.a as I described earlier. So,
> > you have to do even less than in the solution you suggest. Just add
> the
> > stub and the classes won't be pulled in... No need to replace files or
> > jars or whatever...
>
> [Lehner, Michael] 
> Yes, this is clear to me, that they all have to be precompiled. I am
> talking about another version of the libgcj.a, which looks like the
> original (only smaller) but filled only with the object files of stubs
> to define every interface which could be accessed by another class.
> I think this would save some time when you want to change your libgcj,
> because you won't have to write your own stubs. On the other hand this
> of course means to do a lot of work in writing these stubs. And I am not
> really sure if it is worthwhile to invest this time to do this work. I
> really don't know how much use this method to reduce the size of an
> executable.

Actually I think that I'm the first one who does it (that way). Also 
it's more a hack to break the depencies instead of something clean. So I 
very much doubt that this will become to be the standard way of handling 
libgcj.a.


> I will leave all the ideas in my head, because I don't know in the
> moment how this all will end up and what way would be the best then.
> Writing stubs for the whole classpath will be a bit too time consuming.

Actually it can all be automated. I have most of it automated already...


> But you said, that you had written stubs for awt,... Can you send they
> perhaps to me? This would save me some time to redo work you already
> did.

I attached the JARs for removing the GUI and for removing javax.crypto.


Marco

Attachment: noGui.jar
Description: Binary data

Attachment: noJce.jar
Description: Binary data