[PATCH v2 0/3] remove all_lwps from gdbserver

[Doug Evans <dje at google dot com>]

On Fri, Jan 24, 2014 at 5:12 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> I did some profiling of gdbserver's attach/detach speed and was
> able to obtain a significant speedup by changing gdbserver to use
> a hashtable to maintain its tables of inferiors and threads.
>
> [In one perf experiment of attach/detach repeated 20 times on a
> program with 1000 threads, the time as measured by gprof went from
> 45sec to 5sec.]
>
> I created a testcase for our perf testsuite but the results there
> don't show the speed as impressively because it can only measure gdb
> not gdbserver.  I may submit it separately anyway.
>
> The patch is in 3 parts:

Here's v2 of this patch series.
I wasn't as happy with my first attempt as I wanted to be.
This version instead removes global all_lwps (which is something I've
always wanted to do anyway).

gdbserver for linux maintains two separate lists of each thread, and
each list contains important data about the thread so that often the
code needs pointers to both entries.  Alas when gdb has a pointer to
the "lwp_info" form of the thread is does a linear search in the
"thread_info" form of the thread list to get that part.  Yikes!

The idea behind this patch is very simple: remove all_lwps: there's no
point in keeping two lists.
[I could just add a backpointer from lwp_info -> thread_info, but that
would just be a quick fix, and we're very early into 7.8 - we have
time to do something better.  I can't think of a good reason to have
two lists.]

The first two patches are prep work.

1/3: gdbserver has a pseudo base-class that is used by all entries in
a struct inferior_list.
Some structs call this "entry" some call it "head".
I renamed them all to "entry" for consistency.
[I could have picked head but then "head" could (I guess) be confusing
between the head of the list and this "baseclass" entry in, e.g.,
struct thread_info.]

2/3: I first tried to convert the lists to hashtables but that ran
into the fact that a lot of the code accesses the implementation of
the list directly.
Blech.
So this patch changes everything outside of inferiors.c to use
published API routines for accessing the lists.

3/3: This is the core of the patch.  More said later in that patch.

btw, I didn't stick with hashtables because while they can work, there
is the added wrinkle that entries in the table can be deleted
(manageable) or added (trickier) while the table is being iterated
over.
I still get a nice speedup sticking with lists so that's what I'm doing for now.