lobotomizing libgcj

Tom Tromey tromey@redhat.com
Fri May 11 09:30:00 GMT 2001

>>>>> "Tony" == Tony Kimball <alk@pobox.com> writes:

Tony> I want to make the smallest possible executable for the sake of
Tony> POTS modem downloaders.

This comes up quite a bit.

We've wanted to be able to configure libgcj in a fairly fine-grained
way for a long time.  However, implementing it is difficult, and it
has never been a high enough priority to do.

One idea is to get "section GC" to work.  This is a feature whereby
each function is put in its own section, and then the linker removes
everything except what is actually used.  g++ can already do this
(well, it might be broken right now, I'm not sure).

There are plenty of other ideas floating around, too.  Ideally, I
suppose, we'd implement all the ones that made sense together.

I think what we want to avoid is more ad hoc configury.  Right now
there is some of that: you can disable the interpreter and java.net
(well, just the native side, which won't really gain you very much).
To me it seems that ad hoc work is hard to maintain (at least at the
level of granularity we would care about) and also in practice doesn't
gain much (due to the highly interconnected nature of the java
libraries).  That is, unless we did some kind of preprocessing on the
java source, which I think we really don't want to do.


More information about the Java mailing list