Figuring out what's doing so much allocation

[Jim Blandy <jimb@red-bean.com>]

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

I was running into a problem (now fixed) in which gc was running
constantly, so I put together the following hack to figure out who was
doing the allocation. Set gc-quit-frequency to something like 20, and
then set debug-on-quit, and you'll get a backtrace every 20th gc. It's
hardly precise, but often one just needs a hint to suss out the cause.

[-- Attachment #2: gc-quit-frequency.patch --]
[-- Type: text/x-patch, Size: 1076 bytes --]

diff --git a/src/alloc.c b/src/alloc.c
index 044e750..3b98301 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4998,6 +4998,14 @@ returns nil, because real GC can't be done.  */)
   int count = SPECPDL_INDEX ();
   EMACS_TIME t1, t2, t3;
 
+  if (gc_quit_frequency) {
+    static int counter = 0;
+    if (--counter == 0)
+      Vquit_flag = Qt;
+    if (counter <= 0)
+      counter = gc_quit_frequency;
+  }
+
   if (abort_on_gc)
     abort ();
 
@@ -6359,6 +6367,7 @@ init_alloc_once (void)
   byte_stack_list = 0;
   staticidx = 0;
   consing_since_gc = 0;
+  gc_quit_frequency = 0;
   gc_cons_threshold = 100000 * sizeof (Lisp_Object);
   gc_relative_threshold = 0;
 }
@@ -6380,6 +6389,9 @@ init_alloc (void)
 void
 syms_of_alloc (void)
 {
+  DEFVAR_INT ("gc-quit-frequency", gc_quit_frequency,
+              doc: /* *Quit every this many GC's. If zero, don't. */);
+
   DEFVAR_INT ("gc-cons-threshold", gc_cons_threshold,
 	      doc: /* *Number of bytes of consing between garbage collections.
 Garbage collection can happen automatically once this many bytes have been