naming conflicts in libgcj.a

[Per Bothner]

Adam Megacz wrote:

> Hrm, is there an advantage to one-package-per-.o instead of
> one-class-per-.o with the naming scheme I mention above
> ("org.xml.sax.Attributes.o")?

At least two:

* Reduced compilation time, because we only have to lookup
(say) StringBuffer once per package vs once per class.

* Reduced duplication of literals (Utf8Consts, mainly).
(I.e. we only need one UtfConst for "java.lang.StringBuffer"
per package rather than one per class that references it.)

> 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++.

> 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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/