[cxx-abi-dev] comparing type_infos (was Re: Patch for throw/catch problems)

[Jakub Jelinek]

On Tue, Aug 14, 2001 at 04:08:49PM -0700, Mark Mitchell wrote:
> 
> Comments about people complaining are valid.  Users trump theory.
> 
> > And no, caching and prelinking don't help here since we're dealing
> > with weak symbols.  Those can't be prelinked and wind up on the
> > conflict list (which uses yet more runtime memory, btw) which gets
> > resolved after the rest of prelinking is complete.
> >
> 
> I think I meant something more ambitious; you create a table of
> what values to relocate into what absolute memory locations,
> and squirrel them away (along with hashes/timestamps of the DSOs
> you were using).  Then, when you load the program, you check that
> all the hashes match and that your DSOs ended up at the addresses
> you expected and then just blast in your dynamic relocations
> using the saved values without bothering to parse the relocation
> sections or without looking up any symbols.
> 
> Would that work, in theory?

That works in reality too, see
http://sources.redhat.com/ml/binutils/2001-07/msg00057.html
ftp://ftp.redhat.com/redhat/linux/beta/roswell/en/os/i386/SRPMS/prelink-0.1.3-2.src.rpm
The issue is that for some C++ applications, the conflict list is
unfortunately huge (say 30000 out of 100000 total relocations) because many
classes are duplicated accross many shared libs. Conflicts are far cheaper than
normal relocations, since they don't need to do any symbol lookup, but still
have the drawback that they write into memory which if nothing on a page
would be modified could be shared and also each one takes 12 resp. 24 bytes
of shareable memory which is read upon startup.

What could trim the conflict list down substantially would be some kind of
lazy virtual methods if the ABI would allow that (something similar to PLTs
for function calls), but with the difference that once resolved, it could be
written back into virtual table, so further virtual method calls would see
no performance slowdown. This way the relocation would be done only when
some virtual table is actually used, thus classes which are never used would
never need relocation of their virtual table. But the precondition for this
would be that no C++ program can ever read method pointers from virtual
tables and compare them for equality.

	Jakub