Re: empty-string refcount contention

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Wed, Apr 02, 2003 at 11:45:58AM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >On Mon, Mar 31, 2003 at 04:31:35PM -0600, Benjamin Kosnik wrote:
> ...
> >This seems like a good bet, but I wonder whether, in a shared library,
> >getting the address of the empty _Rep object itself involves looking
> >up a relocation, and thus itself requires a bus cycle?  (If so, at 
> >least it's not volatile, thus cacheable.)  Is there any way to ensure 
> >that the address of the empty _Rep object is entirely inlineable, so 
> >that address comparisons don't require a bus cycle?
> 
> Intersting. I don't know the answer to this (I didn't even think
> about it), but it occurs to me that making sure that the object
> is not defined in the shared library (but instead in the executable,
> which may be a third party shared library, that links with it) might
> eliminate this potential problem.

I thought about that alternative, and I don't think it helps.  You 
would have to make sure it appears in the main program and not any 
user library, and even then code instantiated in libstdc++.so or in
user libraries would have to use a relocation to get to it.  (Anyway
I don't know how to force data to be instantiated only in the main 
program.)

It's probably not hard to get basic_string<T>::_S_empty_rep_storage 
for T in {char, wchar_t} instantiated in (and not exported from) 
libstdc++.so, but where should instantiations for other T go, and how 
can we get them there?  

Nathan Myers
ncm-nospam at cantrip dot org