Figuring out what's doing so much allocation

Figuring out what's doing so much allocation

[Jim Blandy]

[-- 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

Re: Figuring out what's doing so much allocation

[Stefan Monnier]

> 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.

Reminds me that we indeed should add some kind of sampling
based profiling.
The sampling could be "every N μs" or "every N allocated bytes", but it
would be really neat to be able to say "Hmm.. what has my Emacs process
been doing for the last 10s" and get some overview.

It shouldn't be that hard to implement, since we have the Lisp backtrace
readily at hand in a global variable.


        Stefan