Re: shriveling libgcj

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

Adam Megacz wrote:

>So my crazy plan to compile a java applet and an activex control from
>a 95% shared codebase is coming along quite well -- I think it'll make
>a nice addition to the "cool stuff people have done with gcj"
>page. The main obstacle remaining is the 16MB libgcj.so.
>
Well, it goes down to ~4MB stripped.

>A few questions to that effect:
>
>- Is there any way for me to get gcj to statically link libgcj to my
>  executable, and prune any dead (unreachable) code?
>
Yes, the linker will remove unreachable classes automatically when you 
link statically. A completely static "Hello world" was around 1.5MB-ish 
on x86 last time I checked, would be smaller with a dynamic libc etc.

>- Unfortunately, I'm pretty sure that this won't help much, since
>     the java.* classes reference each other quite a bit, even though
>     my code never follows most of the execution paths... If I
>     manually remove the .o's from libgcj.a that I "know" I don't
>     need, will I have troubles with the linker complaining and
>     refusing to generate a binary? Can I override this?
>
Yeah, this is the problem with static linking. The linker will include 
all (virtual) methods for any referenced class, and all classes that 
they reference, and so on, which means that a lot of stuff gets included 
that may never be used.

Changes to the linking model could help to overcome this. The 
"-fassume-compiled" (-fno-assume-compiled?) option is supposed to allow 
you to do this by excluding certain packages or classes, but it isn't 
working yet. An extension to this idea is to add code to libgcj that 
dumps out a list of all the classes which actually get loaded by your 
application. Then, after a few test runs which excercise all execution 
paths, you could feed this list back into the compiler. Classes not on 
the list would not get linked, but rather references to them would be 
compiled into something similar to a Class.forName(). If your app tried 
to use a class that was not included in the static binary, you'd get a 
ClassNotFoundException rather than a link-time error. This approach 
would also fix the problem of dynamically (forName) loaded classes not 
being included in your binary.

Search the list archives for past threads on this...

>- If I use CNI only (no JNI), can I ditch jni.o?
>
Sure, you'll probibly have to tweak libgcj though.

>- My code barely uses threads at all -- the only reason I still need
>  them is that there is no non-blocking version of "new Socket()" (it
>  blocks until the connection is accepted). Is there an option for
>  cooperative (green?) multithreading that would let me ditch
>  posix-threads.o?
>

Nope. Its posix threads or no threads. I don't think ommitting 
posix-threads will save you much, though, at least if glibc and 
linuxthreads are to be dynamically linked.

>- If I never load bytecodes at runtime, can I ditch interpret.o? How
>  about defineclass.o?
>
>- What does resolve.o do? name-finder.o? shs.o? ltdl.o?
>
Yes and yes, see above. name-finder is for stack traces (might want to 
keep it?), ltdl is for dynamically loading shared libraries. I think 
you'll find that, with the exception of the interpreter perhaps, the 
size of these is minimal compared to all the unneeded Java crap that 
gets linked though.

>- Is there another garbage collector besides boehm? Is it larger or
>  smaller (binary size)?
>
Not that anyone has released, afaik.

regards

Bryce.