Re: Executable size problem

[Andrea aime <andrea dot aime at aliceposta dot it>]

Andrew Haley wrote:
> Andrea aime writes:
>  > 
>  > I'm wondering, why every class of the standard runtime has to
>  > be compiled into the simple hello world style app?
>
> It isn't.  If you use -Wl,-Map,map while linking you'll get a map file
> that shows you what classes are required and why they are required.
> It starts like this and goes on for a very long time:
>
>
> Archive member included because of file (symbol)
>
> /usr/local/lib/libgcj.a(prims.o)
>                               /tmp/ccmjvhy6.o (_Jv_AllocObjectNoFinalizer)
> /usr/local/lib/libgcj.a(jni.o)
>                               /usr/local/lib/libgcj.a(prims.o) (_Jv_JNI_Init())

I'll try... I've compiled the same hello world style app with gcj 3.4
(from thisiscool.com) and the executable is much smaller (around 2 MB
if my memory helps me). Has the set of required classes grown so much
during the 3.4/4.0 timeframe?

> Not entirely, but the problems associated with static linkage aren't
> only related to dynamic loading.  For example, library bug fixes
> become quite ineffective with static linkage.  Also, you don't get the
> benefit of sharing the same libraries between different processes.  I
> understand dynamic linkage isn't popular on Windows for a variety of
> reasons, but I'm certain that it's a bad idea on GNU/Linux.

I understand these reasons, and they play well in a Linux distribution,
but as you said, on Windows they may lead to a disaster. Moreover, 
should I compile the libraries into dll's instead of statically linking
them, would the memory usage change? (consider that under Windows the
probability that someone is using the same libraries is more or less zero).
From what I've seen so far, the same app running on Sun Java 1.5 starts
as fast as the 30MB executable and uses slightly less memory...
Given that gcj is an additional step in the compilation of the app,
the only tangible benefits so far are better IP protection (makes
reverse engineering harder) and no requirement for a java runtime
(which is usually not a problem in the kind of apps I write at work).
My hope was that native compilation would provide some performance
improvement, especially less RAM usage...

Best regards
Andrea Aime