Thread local storage

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

Hello,

[Gmane swallowed the original message with ID <87hbuf8ddq.fsf@inria.fr>
so I'm resending it.  Beware of Gmane...]

I looked again at how/whether we could improve thread-local storage
access, using compiler support (the ‘__thread’ storage class).

There’s now only one thread-local datum in libguile, which is the
pointer to the current thread.  It’s accessed mostly when running
‘SCM_TICK’ (at least on every ‘call’, ‘goto/args’, or ‘return’ VM
instruction) and when dealing with dynwinds and dynamic state.

There are 4 TLS access models [0]:

  1. The ‘general-dynamic’ model (the default), involves run-time
     overhead slightly lower than ‘pthread_getspecific ()’, but
     comparable when there are few thread-local variables.

  2. The ‘local-dynamic’ model can be used when thread-local variables
     are only referenced from within the shared object they appear in.
     It is not advantageous when only one thread-local variable is used
     (per Section 4.2 of [0]), which is our case.

  3. The ‘initial-exec’ model noticeably reduces the run-time overhead.
     In addition to the restrictions in for ‘local-dynamic’, the shared
     object must be present when the executable is loaded and cannot be
     dlopened.

  4. The ‘local-exec’ model, an optimization of the above, which can
     only be used when the executable is statically linked against
     libguile and its dependencies.

So #3 is appealing (~8% speedup on ‘gcbench’, ~10% on 30 iterations of
‘nboyer’).  Unfortunately it’s not generally applicable to libguile
since libguile may be dlopened (e.g., the XChat-Guile plug-in).
(Actually, according to [1], we should be able to use it on GNU systems
since we don't use much TLS, but in practice it breaks the allocation of
libgc's TLS for some reason.  See attached test program.)

So we’re left with #1, which doesn’t buy us much performance-wise (for
‘general-dynamic’: ~3% speedup on ‘gcbench’, ~4% on 30 iterations of
‘nboyer’.)

The relevant work in ‘wip-tls’:

  commit 8346727c49c51a9668f10b507daff62dd889850a
  Author: Ludovic Courtès <ludo@gnu.org>
  Date:   Fri Oct 2 15:02:52 2009 +0200

      Deprecate `scm_mask_ints'.

  commit b9619bff4ddff267149e7e869ef3c2bcb9c4f4b4
  Author: Ludovic Courtès <ludo@gnu.org>
  Date:   Fri Oct 2 15:28:29 2009 +0200

      Arrange so that `SCM_I_CURRENT_THREAD' is not accessed outside of libguile.

  commit a24c958689c86ac520b73bc9c6e1c40cfbf6f857
  Author: Ludovic Courtès <ludo@gnu.org>
  Date:   Fri Oct 2 16:32:34 2009 +0200

      Use TLS when available for `SCM_I_CURRENT_THREAD'.

Given the second commit, changing the TLS access model for libguile
doesn’t change the ABI.  Power users can compile Guile with the TLS
model of their choice, which is nice.  ;-)

Comments?

Thanks,
Ludo’.

[0] http://people.redhat.com/drepper/tls.pdf
[1] http://thread.gmane.org/gmane.comp.lib.phil/619



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: the dlopen(3) test program --]
[-- Type: text/x-csrc, Size: 476 bytes --]

#include <dlfcn.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
  void *lib;
  void (*init) (void);
  void * (*eval) (const char *);

  lib = dlopen ("libguile.so", RTLD_LAZY);
  init = dlsym (lib, "scm_init_guile");
  eval = dlsym (lib, "scm_c_eval_string");

  init ();
  eval ("(format #t \"hello, world~%2 + 2 = ~A~%\" (+ 2 2))");

  return EXIT_SUCCESS;
}

/*
   Local Variables:
   compile-command: "gcc -g -Wall -o tls-dlopen tls-dlopen.c -ldl"
   End:
 */