This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: naming conflicts in libgcj.a
Per Bothner <per@bothner.com> writes:
> > I only mention this because putting each package into a .o will cause
> > a huge increase in the size of static binaries.
> Separate .o files per class is just an incomplete solution anyway.
> We want each *method* to be able to be linked in independently.
> And then we want some intelligence to avoid pulling in unreferenced
> virtual functions - as has been implemented for C++.
Right. Can anybody point me to documentation on the algorithm used by
vtable-gc? I did some pretty agressive stuff in method-gc, and I'd be
surprised if vtable-gc does the same.
One example: method-gc will not consider any non-static method
"reachable" until it is certain that at least one of the class's
constructors (or a subclass's constructor) is "reachable". I'm curious
if the special vtable-gc annotations in .o's are detailed enough to
allow this degree of global analysis.
I'm still somewhat reliant on file-granularity dead-code elimination
in the linker to take care of symbols in the data segment -- method-gc
only deals with methods, not static data. If all of a class's methods
get purged, even the mingw linker is smart enough to drop the rest of
the .o that it belongs to.
> > If I coded up the configure magic to make this a compile-time choice,
> > would it be likely to be accepted?
> I think so, but compile-package-at-once should be the default.
Cool. It's useful on platforms (win32) that don't support section-gc
or vtable-gc. I'd love to see high-quality dead code elimination built
into gcj, though.
- a