empty-string refcount contention

[Ulrich Drepper]

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

Nathan Myers 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?

The answer depends on many factors.

First, I assume that the empty string object is not exported.  This is
really important, without it the operation is prohibitively expensive.

Then it depends on the CPU architecture.  For x86, getting the address
of an internal object seems very simple

   leal  emptystring@GOTOFF(%ebx), %eax

but this assumes that the %ebx register has the correct GOT address
already loaded.  If you have a tiny little function which only returns a
reference to the emptystring object then %ebx has to be loaded with
something like

   call 0f
 0:popl %ecx

   leal emptystring@GOTOFF(%ecx), %eax

(or the equivalent generated for i686 and up which looks different).
This piece of code is also generated only be modern gccs, older ones
always use %ebx which means the content register has to be preserved.

If the code is completely inlined in a larger function which also
accesses global objects or calls exported functions the %ebx register is
already loaded and the leal instruction is the only one needed which
makes the code cheap again.


Anyway, on more modern architectures (like Hammer for instance) such an
ugly construct isn't needed since the processor has a PC-relative data
addressing mode.  Therefore code like

  leaq emptystring@GOTOFF(%rip), %rax

is the only code needed.  Always.

- -- 
- --------------.                        ,-.            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+izDp2ijCOnn/RHQRAmIVAJ9tZ/A7KVAdIFX3qmHgHC/vcPYRBQCfab3R
wE81EjUlPG+l8sHsD0JSawg=
=JpvQ
-----END PGP SIGNATURE-----