shriveling libgcj

[Adam Megacz <gcj at lists dot megacz dot com>]

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.

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?

   - 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?

- If I use CNI only (no JNI), can I ditch jni.o?

- 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?

- 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?

- Is there another garbage collector besides boehm? Is it larger or
  smaller (binary size)?

Thanks!

  - a

-- 
If the Boston Tea Party happened today, our politicians would denounce
it as an act of Terrorism.