empty-string refcount contention
Nathan Myers
ncm-nospam@cantrip.org
Wed Apr 2 23:01:00 GMT 2003
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@cantrip.org
More information about the Libstdc++
mailing list