public inbox for rda@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: rda@sources.redhat.com
Subject: [RFC] Improve performance of multi-threaded debugging
Date: Wed, 14 Sep 2005 22:04:00 -0000	[thread overview]
Message-ID: <20050914150439.5a86df49@ironwood.lan> (raw)

As things stand now, the thread list is fetched each time rda checks
the status of the program.  This doesn't sound like such a burden until
you realize that some decent sized data structures are read via the
ptrace() interface.  On slower machines, it can take a significant amount
of time to single step or continue primarily due to this overhead.

The patch below fetches the thread list only when it knows for certain
that something has changed.

The only fly in the ointment is that the signal based event model only
knows about thread creation, but not about thread death.  So it won't
catch thread death until some new thread is created.  I'm not sure
what the implications of this are in practice.

Comments?

	* thread-db.c (ALWAYS_UPDATE_THREAD_LIST): Define to be 0.
	(handle_thread_db_event): Update thread list upon receipt of
	TD_CREATE or TD_DEATH events.
	(thread_db_check_child_state): Potentially disable, depending upon
	value of ALWAYS_UPDATE_THREAD_LIST, the thread list update.
	(thread_db_check_child_state): Update thread list for signal based
	event model too.

Index: thread-db.c
===================================================================
RCS file: /cvs/cvsfiles/devo/rda/unix/thread-db.c,v
retrieving revision 1.25.2.1
diff -u -p -r1.25.2.1 thread-db.c
--- thread-db.c	3 Aug 2005 05:20:58 -0000	1.25.2.1
+++ thread-db.c	14 Sep 2005 21:31:48 -0000
@@ -48,6 +48,8 @@
 int thread_db_noisy = 0;
 int proc_service_noisy = 0;
 
+#define ALWAYS_UPDATE_THREAD_LIST 0
+
 /*
  * A tiny local symbol table.
  *
@@ -1779,6 +1781,7 @@ handle_thread_db_event (struct child_pro
   struct gdbserv_thread *thread = process->event_thread;
   lwpid_t lwp;
   union wait w;
+  int do_update = 0;
 
   /* We need to be actually using the event interface.  */
   if (! using_thread_db_events)
@@ -1812,13 +1815,16 @@ handle_thread_db_event (struct child_pro
 	  break;
 	}
 
-      /* The only messages we're concerned with are TD_CREATE and
-	 TD_DEATH.
+      if (msg.event == TD_CREATE || msg.event == TD_DEATH)
+	do_update = 1;
+    }
 
-	 Every time thread_db_check_child_state gets a wait status
-	 from waitpid, we call update_thread_list, so our list is
-	 always up to date; we don't actually need to do anything with
-	 these messages for our own sake.  */
+  if (do_update)
+    {
+#if !ALWAYS_UPDATE_THREAD_LIST
+      /* Update the thread list.  */
+      update_thread_list (process);
+#endif
     }
 
   /* Disable the event breakpoints while we step the thread across them.  */
@@ -2122,9 +2128,11 @@ thread_db_check_child_state (struct chil
 		     process->stop_signal,
 		     (unsigned long) debug_get_pc (process->serv, process->pid));
 
+#if ALWAYS_UPDATE_THREAD_LIST
 	  /* Update the thread list, and attach to (and thereby stop)
              any new threads we find.  */
 	  update_thread_list (process);
+#endif
 
 	  process->event_thread = thread_list_lookup_by_lid (process->pid);
 
@@ -2170,6 +2178,12 @@ thread_db_check_child_state (struct chil
 		    process->stop_signal = restart_signal;
 		  else				/* not main thread */
 		    process->stop_signal = 0;
+
+#if !ALWAYS_UPDATE_THREAD_LIST
+		  /* Update the thread list.  */
+		  update_thread_list (process);
+#endif
+
 		}
 	      process->signal_to_send = process->stop_signal;
 	      currentvec->continue_program (serv);

             reply	other threads:[~2005-09-14 22:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-14 22:04 Kevin Buettner [this message]
2005-09-14 22:09 ` Daniel Jacobowitz
2005-09-14 22:31   ` Kevin Buettner
2005-09-16 20:13 ` Jim Blandy
2005-09-16 20:20 ` Jim Blandy
2005-09-16 20:49   ` Kevin Buettner
2005-09-17  0:19     ` Jim Blandy
2005-11-04 21:16 ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050914150439.5a86df49@ironwood.lan \
    --to=kevinb@redhat.com \
    --cc=rda@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).