[09/11] gdb: optimize selection of resumed thread with pending event

Message ID 20210622165704.2404007-10-simon.marchi@polymtl.ca
State New
Headers show
Series
  • Various thread lists optimizations
Related show

Commit Message

Eli Zaretskii via Gdb-patches June 22, 2021, 4:57 p.m.
Consider a case where many threads (thousands) keep hitting a breakpoint
whose condition evaluates to false.  random_pending_event_thread is
responsible for selecting a thread from an inferior among all that are
resumed with a pending wait status.  It is currently implemented by
walking the inferior's thread list twice: once to count the number of
candidates and once to select a random one.

Since we now maintain a per target list of resumed threads with pending
event, we can implement this more efficiently by walking that list and
selecting the first thread that matches the criteria
(random_pending_event_thread looks for an thread from a specific
inferior, and possibly a filter ptid).  It will be faster especially in
the common case where there isn't any resumed thread with pending
event.  Currently, we have to iterate the thread list to figure this
out.  With this patch, the list of resumed threads with pending event
will be empty, so it's quick to figure out.

The random selection is kept, but is moved to
process_stratum_target::random_resumed_with_pending_wait_status.  The
same technique is used: do a first pass to count the number of
candidates, and do a second pass to select a random one.  But given that
the list of resumed threads with pending wait statuses will generally be
short, or at least shorter than the full thread list, it should be
quicker.

Note that this isn't completely true, in case there are multiple
inferiors on the same target.  Imagine that inferior A has 10k resumed
threads with pending wait statuses, and random_pending_event_thread is
called with inferior B.  We'll need to go through the list that contains
inferior A's threads to realize that inferior B has no resumed threads
with pending wait status.  But I think that this is a corner /
pathological case.  And a possible fix for this situation would be to
make random_pending_event_thread work per-process-target, rather than
per-inferior.

gdb/ChangeLog:

	* process-stratum-target.h (class process_stratum_target)
	<random_resumed_with_pending_wait_status>: New.
	* process-stratum-target.c
	(process_stratum_target::random_resumed_with_pending_wait_status):
	New.
	* infrun.c (random_pending_event_thread): Use
	random_resumed_with_pending_wait_status.

Change-Id: I1b71d01beaa500a148b5b9797745103e13917325
---
 gdb/infrun.c                 | 40 +++++++++------------------------
 gdb/process-stratum-target.c | 43 ++++++++++++++++++++++++++++++++++++
 gdb/process-stratum-target.h |  5 +++++
 3 files changed, 59 insertions(+), 29 deletions(-)

-- 
2.32.0

Comments

Pedro Alves July 5, 2021, 3:51 p.m. | #1
On 2021-06-22 5:57 p.m., Simon Marchi via Gdb-patches wrote:
> Consider a case where many threads (thousands) keep hitting a breakpoint

> whose condition evaluates to false.  random_pending_event_thread is

> responsible for selecting a thread from an inferior among all that are

> resumed with a pending wait status.  It is currently implemented by

> walking the inferior's thread list twice: once to count the number of

> candidates and once to select a random one.

> 

> Since we now maintain a per target list of resumed threads with pending

> event, we can implement this more efficiently by walking that list and

> selecting the first thread that matches the criteria

> (random_pending_event_thread looks for an thread from a specific

> inferior, and possibly a filter ptid).  It will be faster especially in

> the common case where there isn't any resumed thread with pending

> event.  Currently, we have to iterate the thread list to figure this

> out.  With this patch, the list of resumed threads with pending event

> will be empty, so it's quick to figure out.

> 

> The random selection is kept, but is moved to

> process_stratum_target::random_resumed_with_pending_wait_status.  The

> same technique is used: do a first pass to count the number of

> candidates, and do a second pass to select a random one.  But given that

> the list of resumed threads with pending wait statuses will generally be

> short, or at least shorter than the full thread list, it should be

> quicker.

> 

> Note that this isn't completely true, in case there are multiple

> inferiors on the same target.  Imagine that inferior A has 10k resumed

> threads with pending wait statuses, and random_pending_event_thread is

> called with inferior B.  We'll need to go through the list that contains

> inferior A's threads to realize that inferior B has no resumed threads

> with pending wait status.  But I think that this is a corner /

> pathological case.  And a possible fix for this situation would be to

> make random_pending_event_thread work per-process-target, rather than

> per-inferior.

> 

> gdb/ChangeLog:

> 

> 	* process-stratum-target.h (class process_stratum_target)

> 	<random_resumed_with_pending_wait_status>: New.

> 	* process-stratum-target.c

> 	(process_stratum_target::random_resumed_with_pending_wait_status):

> 	New.

> 	* infrun.c (random_pending_event_thread): Use

> 	random_resumed_with_pending_wait_status.


OK.

Patch

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 657f97e23fbb..80834fed1e3b 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -3493,39 +3493,21 @@  print_target_wait_results (ptid_t waiton_ptid, ptid_t result_ptid,
 static struct thread_info *
 random_pending_event_thread (inferior *inf, ptid_t waiton_ptid)
 {
-  int num_events = 0;
+  process_stratum_target *proc_target = inf->process_target ();
+  thread_info *thread
+    = proc_target->random_resumed_with_pending_wait_status (inf, waiton_ptid);
 
-  auto has_event = [&] (thread_info *tp)
+  if (thread == nullptr)
     {
-      return (tp->ptid.matches (waiton_ptid)
-	      && tp->resumed ()
-	      && tp->has_pending_waitstatus ());
-    };
-
-  /* First see how many events we have.  Count only resumed threads
-     that have an event pending.  */
-  for (thread_info *tp : inf->non_exited_threads ())
-    if (has_event (tp))
-      num_events++;
-
-  if (num_events == 0)
-    return NULL;
-
-  /* Now randomly pick a thread out of those that have had events.  */
-  int random_selector = (int) ((num_events * (double) rand ())
-			       / (RAND_MAX + 1.0));
-
-  if (num_events > 1)
-    infrun_debug_printf ("Found %d events, selecting #%d",
-			 num_events, random_selector);
+      infrun_debug_printf ("None found.");
+      return nullptr;
+    }
 
-  /* Select the Nth thread that has had an event.  */
-  for (thread_info *tp : inf->non_exited_threads ())
-    if (has_event (tp))
-      if (random_selector-- == 0)
-	return tp;
+  infrun_debug_printf ("Found %s.", target_pid_to_str (thread->ptid).c_str ());
+  gdb_assert (thread->resumed ());
+  gdb_assert (thread->has_pending_waitstatus ());
 
-  gdb_assert_not_reached ("event thread not found");
+  return thread;
 }
 
 /* Wrapper for target_wait that first checks whether threads have
diff --git a/gdb/process-stratum-target.c b/gdb/process-stratum-target.c
index 44e138273b2f..c828da0f3bca 100644
--- a/gdb/process-stratum-target.c
+++ b/gdb/process-stratum-target.c
@@ -20,6 +20,7 @@ 
 #include "defs.h"
 #include "process-stratum-target.h"
 #include "inferior.h"
+#include <algorithm>
 
 process_stratum_target::~process_stratum_target ()
 {
@@ -140,6 +141,48 @@  process_stratum_target::maybe_remove_resumed_with_pending_wait_status
 
 /* See process-stratum-target.h.  */
 
+thread_info *
+process_stratum_target::random_resumed_with_pending_wait_status
+  (inferior *inf, ptid_t filter_ptid)
+{
+  auto matches = [inf, filter_ptid] (const thread_info &thread)
+    {
+      return thread.inf == inf && thread.ptid.matches (filter_ptid);
+    };
+
+  /* First see how many matching events we have.  */
+  const auto &l = m_resumed_with_pending_wait_status;
+  unsigned int count = std::count_if (l.begin (), l.end (), matches);
+
+  if (count == 0)
+    return nullptr;
+
+  /* Now randomly pick a thread out of those that match the criteria.  */
+  int random_selector
+    = (int) ((count * (double) rand ()) / (RAND_MAX + 1.0));
+
+  if (count > 1)
+    infrun_debug_printf ("Found %u events, selecting #%d",
+			 count, random_selector);
+
+  /* Select the Nth thread that matches.  */
+  auto it = std::find_if (l.begin (), l.end (),
+			  [&random_selector, &matches]
+			  (const thread_info &thread)
+    {
+      if (!matches (thread))
+	return false;
+
+      return random_selector-- == 0;
+    });
+
+  gdb_assert (it != l.end ());
+
+  return &*it;
+}
+
+/* See process-stratum-target.h.  */
+
 std::set<process_stratum_target *>
 all_non_exited_process_targets ()
 {
diff --git a/gdb/process-stratum-target.h b/gdb/process-stratum-target.h
index c73207e0531e..4d1d14f7a94f 100644
--- a/gdb/process-stratum-target.h
+++ b/gdb/process-stratum-target.h
@@ -93,6 +93,11 @@  class process_stratum_target : public target_ops
   bool has_resumed_with_pending_wait_status () const
   { return !m_resumed_with_pending_wait_status.empty (); }
 
+  /* Return a random resumed thread with pending wait status belonging to INF
+     and matching FILTER_PTID.  */
+  thread_info *random_resumed_with_pending_wait_status
+    (inferior *inf, ptid_t filter_ptid);
+
   /* The connection number.  Visible in "info connections".  */
   int connection_number = 0;