lobotomizing libgcj

Bryce McKinlay bryce@waitaki.otago.ac.nz
Thu May 10 19:26:00 GMT 2001

Tony Kimball wrote:

> I want to make the smallest possible executable for the sake of POTS
> modem downloaders.  I thought removing the ClassLoader and
> SecurityManager support would be good first steps at reducing
> statically linked size.  Any other suggestions?

Interpreter support can be removed with --disable-libgcj-interpreter, and
removing the static references to protocol drivers in gnu.gcj.FirstThread
should stop a lot of java.net stuff being linked in if you don't need
that. I'd also look at natSystem.cc and see what classes can be omitted
from property initialization.

Although I like the idea in principle of making more of the runtime
conditionally compiled, this is going to be hard to do in most cases
without doing nasty things like putting preprocessor directives in java
source code.

Instead, the best solution IMO is to implement a linking model which
allows certain classes or packages to be compiled as weak references, and
having the compiler insert code to dynamically load these classes (which
gets called at the right time wrt the JLS). This code would essentially
call Class.forName() to load the class, and a ClassNotFoundException
would be thrown if a class is required at runtime but could not be found.
This has the nice side effect of permitting compiled classes to link
against .class files (although I'm not sure how useful this would really
be in a production environment since layout changes to the class files
would break native classes compiled against them).

It would be easy to add code to libgcj to dump out a list of all classes
used (initialized) by your application at runtime, and then feed that
list back into gcj and have it compile references to all other classes
using this weak linking model (or simply to throw a
ClassNotFoundException if an exectution path which requires that class is
taken). This means that gcj will be recompiling all of the application's
dependent classes, but I don't think would be a problem for final,
production builds (especially as the speed of the compiler improves).

Implementing class metadata compression will also help reduce the bloat


  [ bryce ]

More information about the Java mailing list