[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DEBUG-INFO-AREA grows to enormous size
Date: Mon, 10 Sep 90 22:54 EDT
From: barmar@Think.COM (Barry Margolin)
Date: Mon, 10 Sep 90 17:28 CDT
From: lgm@iexist.att.com
What all goes into the
DEBUG-INFO-AREA, and who is the likely culprit in this case?
Debug info goes in DEBUG-INFO-AREA, of course! Debug info includes
argument list descriptions, local variable descriptors, some
declarations, etc; basically, it's the stuff that shows up in "Extra
info" when you DESCRIBE a compiled function object.
This is a static area for the same reason that COMPILED-FUNCTION-AREA
is: most of the time you don't redefine functions alot, so very little
of the stuff in these areas ever becomes garbage. Even if you are doing
lots of redefinition, though, it seems pretty hard to waste a
significant amount of memory with garbage debug info; a large function
might have a few dozen words of debug info. Perhaps your application
(or Statice, maybe) compiles lots of functions on the fly and then
throws them away?
Either that or your application is requesting information about lots of
Genera's compiled functions. The debug info for Genera's compiled
functions is stored in compressed form, and is expanded into its normal
form on demand. By default, the expanded debug info for a function is
created in permanent storage and substituted for the compressed version,
so it doesn't need to be reexpanded the next time around. You can
change this behavior with this:
;; Just expand debugging info into working storage and let the GC clean it up.
(setq si:*store-back-expanded-extra-info* nil)
This reduces storage requirements at some cost in runtime performance
and a slightly larger working set due to the compression data
structures. I use this mode with no apparent ill effects.
If your pattern of function creation doesn't fit Genera's assumption you
might want to create a couple of new areas and set or bind
SYS:COMPILED-FUNCTION-AREA and SI:DEBUG-INFO-AREA to them.
barmar