Re: Prelinking of shared libraries

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> You forget about the ones in the .data section (due to vtables) In 
> libkdeui.so.3.0.0 (Latest KDE CVS) I have 15547 relocations of the type 
> R_386_32 and 12759 of those refer to qt symbols. Most of those seem to come 
> out of the .data section.
[...]
> No. What currently happens is that the .text and .plt of a lib are shared 
> between processes but that each process has its own .got and .data.

So it appears that you claim that "most" overhead comes from the loss
of sharing, and the need to page-in (or copy-on-write) the data
sections, and the got.

If this is indeed your claim, can you give some proof to support it?
E.g. how many pages need to be copied? In kdeui.so.2, .got has just 3
pages of memory (.data has 5 pages) ...

Looking at the issue of vtables specifically: what fraction of the
.data section do they typically occupy? It might be the vtables
themselves are small, but that they appear on most pages of the data
section.

If that is the case, grouping all vtables together in the DSO might
already reduce startup costs.

> If you only take the relocations that don't depend on symbols, you will have 
> to make sure that the different type of entries are grouped so that you have 
> a whole page with only R_386_RELATIVE that you can share. But looking at the 
> numbers, you will have a hard time filling even a single page, so that is 
> unlikely to lead to any significant improvement.

Why is that? The .eh_frame and .gcc_except_table sections are *only*
relocated using R_386_RELATIVE relocations. On my copy of libkdeui.so,
they combine to 15 pages.

> Besides I doubt whether you have enough control over the layout of
> the .data section to pull that off.

Not sure what "that" is here. If significant speed improvements can be
achieved by systematically re-arranging the elements of the .data
section, I think gcc and/or ld could be taught to execute such
control.

Regards,
Martin