Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

On Thu, 2019-05-30 at 20:48 -0600, Tom Tromey wrote:
> Tom> Locally I only saw utilization of 1.5 CPUs or so -- so, not very
> Tom> parallel yet.
> 
> I found the "mutrace" tool and it looks like the new mutex is heavily
> contended.  This is pretty much what I suspected, but still unfortunate.
> 
> $ mutrace -d ./gdb -nx -batch ./gdb
> [...]
>  Mutex #   Locked  Changed    Cont. tot.Time[ms] avg.Time[ms] max.Time[ms]  Flags
>        2  3714780    45723    26425      975.514        0.000       22.141 M-.--.
> 
> I'm not really sure what to do about it.
Use lockless data structures (e.g. concurrencykit.org) ?

But I am quite sure such lockless libraries/data structures will not
be available on all supported GDB platforms, so it might not be very
cheap to change and maintain GDB to use e.g. lockless hash tables
on some platforms and some other hash tables in less common platforms.

Alternatively, develop a few GDB specific lockless data structures
that are protected by a mutex and/or are single threads on less
common platforms ?

> 
> I do wonder if there are many duplicates when demangling minsym names.
> One idea would be to demangle in parallel and only then fill in the
> table.
> 
> A similar problem will occur when/if we want to parallelize psymbol
> reading.  Those use the demangle hash table, but also the bcache.  (The
> bcache is important, but I found recently that the demangling isn't
> really needed -- the names are demangled due to the physname work, and
> the demangle hash table is only used to ensure that the bcache gives
> good results.  Removing the demangling step here can also provide a nice
> speedup...)
> 
> Tom