Dave Korn wrote: > 1) Would this be a reasonable approach, specifically i) in adding a configure > option to cause sublibraries to be built, and ii) in using gmake's $(filter) > construct to crudely subdivide the libraries like this?
At program startup the first library would be loaded, it would load the next, and so on. There are a few parts of libgcj that are truly independent, but I suspect that you'd always load almost all of it. So, you'd have longer startup time for loading all those files. With regard to GNU libc platforms: You'd no longer be able to make so much use of fast calls between functions in the same library; you'd have to go via the PLT. Also, dl_iterate_phdr() is used a great deal (for finding exception regions, garbage collection, etc.) and it linearly scans the libraries that are loaded. So, the more libraries you have loaded, the slower it goes. Now, I don't know how much of these characteristics are shared by Windows, but I imagine some of them are. So, I suspect your best bet would be to split libgcj into core and non-core libraries and not slice much more thinly than that. I can advise you what is core and what isn't. Andrew.
