lobotomizing libgcj
Tom Tromey
tromey@redhat.com
Sun May 13 08:04:00 GMT 2001
>>>>> "Tony" == Tony Kimball <alk@pobox.com> writes:
Tony> How about emitting a .o per method, as well as one for the
Tony> class?
This doesn't gain us anything. Because we use vtables we need
compiler and linker help in order to do selective linking. At that
point you might as well use section GC, since it is already supported
and doesn't require a lot of compiler work (right now I don't think
the compiler has the machinery to generate multiple .o's in a single
invocation).
Tony> (I'm working on removing jni.o right now. It's 3x larger than
Tony> interp.o.)
Tell us what you find out. I think it should drop out cleanly.
If you don't need reflection then getting rid of the reflection data
would probably be a fairly big win. This requires compiler changes.
There may also be places that depend on reflection in nonobvious ways.
For instance, i/o charset conversions need some reflection data.
Tom
More information about the Java
mailing list