Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!islington-terrace.csc.ti.com!pf
From: pf@islington-terrace.csc.ti.com (Paul Fuqua)
Newsgroups: comp.sys.ti.explorer
Subject: Re: Running out of address space
Message-ID: <2823022520-10590044@Islington-Terrace>
Date: 16 Jun 89 20:55:20 GMT
References: <acuff@sumex-aim.stanford.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 50


    Date: Friday, June 16, 1989  2:45pm (CDT)
    From: Richard Acuff <acuff at sumex-aim.stanford.edu>
    Subject: Running out of address space
    
       I believe this is a problem, and I believe the problem will get worse if
    indicated changes in Rel 6 happen.  The default for
    SYS:*GC-MAX-INCREMENTAL-GENERATION* will be reduced from 2 to 1, and the
    thresholds for 1 and 2 will be reduced to 20% of RAM and 40% of RAM
    respectively.  I think this implies that garbage will accumulate in
    generation 2.

I've been using a pre-release 6.0 band for a few months now, and the
last couple have had the indicated GC parameters.  In fact, I noticed
the increased number of level 1 and 2 collections and reported the new
thresholds as a bug.
    
	    This may very well be a good tradeoff against performance since in
    most cases the amount collected from generation 2 is quite small but it takes
    a lot of time to collect, but it is still unsafe.

My usual long-term garbage percentage in level 2 is 15%.  I'm one of
those people who like to run for weeks at a time between boots.
    
    3. Allow the user to tune the generation thresholds.  Thus if I have a
       program that cons more than 40% of RAM, holds onto most of it for a while,
       and then drops it, I can tune the system to that without having to resort
       to batch GC.

I want this.  I want to go back to the original generation sizes, more
or less.  I want at least the TGC equivalent of the old flip-ratio
control.  It would be trivial to change the threshold constants (and I
may do this privately).

What I do at the moment is set the max incremental generation to 2 and
run a background process that wakes up at 4:00am and does
(gc-immediately :max-gen 3 :promote nil) after flushing histories and
kill rings.  (Kill rings and input histories are often-forgotten sources
of long-term pointers to nearly everything.)  That tends to find about
15% of level 3 as garbage.
    
    Please let me know what you think about this issue.

As customers, you have much greater influence than internal TI people
like me, so speak up.

Paul Fuqua                     pf@csc.ti.com
                               {smu,texsun,cs.utexas.edu,rice}!ti-csl!pf
Texas Instruments Computer Science Center
PO Box 655474 MS 238, Dallas, Texas 75265