This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: empty-string refcount contention


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathan Myers wrote:

> If it's not exported, then (since this is a static member of a class 
> template) would there be a separate copy instantiated in each shared 
> library that mentions it?

Yep.


> Inlined comparisons in other DSOs (and in
> the main program) would refer to the local copy, then, and fail, since 
> strings are always constructed in libstdc++.so.

Yes.


> I believe that in the current implementation, the refcount _is_
> exported (and is always touched).  What really happens when its address 
> is computed?

Read the DSO paper.  The whole name lookup process is used when the
empty string object is used in a DSO (i.e., it's done once per DSO).
And then determining the address requires an actual memory access.  The
address value, determined by the name lookup, has to be loaded from the GOT.


> Might the cost of getting that global address far exceed 
> any advantage from inlining operations on it, regardless of whether we 
> try to optimize away touching it?

I cannot answer this.  The cost for any non-local access is
non-neglectable.  And one more: if on platforms like x86 you end up with
copy relocations you will never again be able to change the size of the
object (well, maybe the size can be decreased but this is also a grey area).

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+i1kQ2ijCOnn/RHQRAmr4AJ44ghRPcu8fX7n8y4KZoif7hnJEBACgkd7R
XeaVelt2JgPQVNEEhv01r0k=
=/5Yk
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]