Re: gcj executable size reduction?

[Adam Megacz <megacz at gcc dot gnu dot org>]

Bryce McKinlay <mckinlay@redhat.com> writes:
> I know some people (Adam Megacz?) have done work in this area. Using

I apoligize for not posting earlier.  I've been superbusy.  If you're
curious, check out http://core.ibex.org (it's a darcs repository) and
look at org.ibex.util.NanoGoat.  I managed to wedge Ibex into 400kb
compressed; I estimate that 250kb of that was libgcj and boehm-gc.

The way it works is this: you compile all your code into bytecode, it
traces reachability (including symbol tables in any CNI code) and
stubs out unreachable method with a one-line "throw new
UnsatisfiedLinkError()".  There are a few more optimizations, but
that's the main gist.

It works great, but still requires hand-tuning for the particular app
you're running it on.

The other change I made was to add -finhibit-reflection, which drops
as much reflection metadata as possible.  Class.forName() still works
and I keep enough method info to use interface dispatch (although I'd
love to do that differently).


> But please don't even think about putting preprocessor directives in
> .java files to try and create optional dependencies.

Postprocessing the bytecode works great for me.  IMHO that's the way
to go.


The Next Frontier is making EH data smaller.  After NanoGoat, that's
by far the easiest target to hit.  DWARF2 is a pile of bloat if you
know that your exceptions are all Java exceptions (read: you can be
much smarter).  Unfortunately there's absolutely no documentation on
how to write a GCC EH personality; we need to talk somebody into doing
this that already knows that stuff.


>> Reducing the size of (statiuc) gcj executables is a big priority for
>> my client, so I'm ready to spend some time on this issue.  It would
>> be helpful to get a feel for what people are already doing, planning
>> on doing, or have given up on doing!

Any luck, Per?

  - a