Re: Static Space filling up

["David D. Loeffler" <Loeffler@mcc.com>]

    Date: Sun, 24 Jan 88 13:34:05 PST
    From: luria@renoir.Berkeley.EDU (Marc Luria)

    From @kl.sri.com:CMP.SLUG@R20.UTEXAS.EDU Mon Dec 21 22:16:23 1987
    Received: from ucbvax.Berkeley.EDU by renoir.Berkeley.EDU (5.58/1.25)
	    id AA27797; Mon, 21 Dec 87 22:16:08 PST
    Received: from KL.SRI.COM by ucbvax.Berkeley.EDU (5.58/1.26)
	    id AA13301; Mon, 21 Dec 87 22:16:01 PST
    Received: from R20.UTEXAS.EDU by KL.SRI.COM with TCP; Mon 21 Dec 87 22:13:09-PST
    Return-Path: <DLA@DIAMOND.S4CC.Symbolics.COM>
    Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3].#Internet) by R20.UTEXAS.EDU with TCP; Mon 21 Dec 87 18:23:09-CST
    Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 152689; Mon 21-Dec-87 19:21:25 EST
    Date: Mon, 21 Dec 87 19:21 EST
    From: David L. Andre <DLA@diamond.s4cc.symbolics.com>
    Subject: Static Space filling up
    To: luria@renoir.Berkeley.EDU
    Cc: slug@r20.utexas.edu
    In-Reply-To: <8712201938.AA19559@renoir.Berkeley.EDU>
    Message-Id: <19871222002111.5.DLA@KOYAANISQATSI.S4CC.Symbolics.COM>
    Resent-Date: Mon 21 Dec 87 22:07:45-CST
    Resent-From: CMP.SLUG@r20.utexas.edu
    Resent-To: SLUG.;@KL.SRI.COM.CMP.SLUG@R20.UTEXAS.EDU
    Resent-Message-Id: <12360396847.36.CMP.SLUG@R20.UTEXAS.EDU>
    Status: R

	Date: Sun, 20 Dec 87 11:38:07 PST
	From: luria@renoir.Berkeley.EDU (Marc Luria)

	The static space starts filling up. After cold boot, show gc status
	shows 11 million, but after a week or so, this gets up to 14.
	si:full-gc gets rid of a couple thousand.  I don't think it
	is due to this broadcast process bug.  I think it has something to do
	with recompiling a lot.  From what I understand the compiled-function-area
	is a static space.  Is there anyway to gc this area?
	Or is there another area which may be filling up?

    The problem cannot be compiled-function-area, since that is not
    reclaimed by full-gc.  Compiled functions can be reclaimed using the
    :Optimize World command.  Why don't you use the ROOM function and find
    out for yourself what areas are filling up?



    I did check, and it seems the main culprit is STACK-AREA
    ?
    This has gone from 2912K used a couple weeks ago, to
    6848K today.  Whereas the type of other regions is List or Struc
    New of Static, the type of the stack region is Stack.  I assume
    that is not garbage collecting the stack space of processes
    which have been killed.  Is there a way to gc this area?

We had a problem here where the  stack space was filling up but  it when
from about 14M  to 40M  (this could  happen in  15 minutes). The problem
ended up being caused by two problems (both were consumers of the  stack
area).  One was a site defined broadcaster server being envoked  several
times a several times a second.  It in turn recreated several  processes
via process-run-function (part of the  system code for default  handling
of   broadcast   servers).       You   can   look   at   the    variable
SI:PROCESS-RUN-FUNCTION-SPARE-PROCESSES and see if you have more than  3
to 5 processes.  When one of these processes gets created initially  you
lose  about  32K  to  64K  of  static  space.    We  fixed  the  problem
temporarily by changing  our broadcaster  server function  definition so
only one process was created and it loaded a queue that another  process
handled.

Another problem we found was a routine that would automatically grow the
stack if it overflowed.  A function was walking over a data structure
recursively and it would sometimes bomb out because of a lack of stack
space.  To keep this from happening an error handler was created that
would grow the stack and then let the function continue to run.  This
was okay until our data structures grew.  The problem was fixed by
creating a more iterative function.

  -- David D. Loeffler