Article View: comp.sys.ti.explorer
Article #17Re: Running out of address space
From: Paul Fuqua
Date: Fri, 16 Jun 1989 20:55
Date: Fri, 16 Jun 1989 20:55
50 lines
2847 bytes
2847 bytes
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
Technical Details
Message-ID:
<2823022520-10590044@Islington-Terrace>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!islington-terrace.csc.ti.com!pfReferences:
<acuff@sumex-aim.stanford.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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