[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GC, ZMail

    Date: Fri, 9 Sep 88 09:50 EDT
    From: mkr%FINGLAS@Warbucks.AI.SRI.COM

     	It is a longstanding bug in the address-space calculations for GC that
     	migration of modified pages from the load file to the paging file is not
     	included in the calculation of how much memory will be used up by GC.
     	This is the phenomenon you're observing.  If you (can) do a second GC,
     	you'll notice that the free space remains the same.  Alternatively, if
     	you netboot, everything is in the paging file initially, so you won't
     	observe the free-space shrinkage there, either.

	The fix is not easy, but not particularly difficult.  It hasn't been
	fixed yet mainly because we're concentrating on other things.

    Alright...let me rephrase the Q.

    When I GC, the info I get when I do a Show GC Status tells me that I
    LOST memory by doing the GC.  I ran NO user programs while GC was
    engaged.

    Which of the following happened:

    a) I really DID loose mem through some bug or feature in GC...

    b) I actually got more mem, but the updated info was not passed
       on to the table used by the Show GC Status command, so it reports
       (erroneously) that there is less mem left.

    I just want to clear this up in my mind...I'll probably end up leaving GC
    off and rebooting occasionally....

You still misunderstand, probably due to my incomprehensible
explanation above.  Let me try again.

"Free memory" really means the amount of memory available IN YOUR PAGING
FILE.  There are a number of things which take up memory in paging
files.  One of them is consing.  If you create a page of objects, they
take up one page in the paging file.  If you GC those objects, then a
page becomes available in the paging file.  This is just as you suspect.

When you boot normally (that is, you don't netboot), no pages are used
in the paging file.  As you create objects, they take up space in the
paging file, and as they go away, space is freed in the paging file.

But wait, you ask, where do all the other objects in the world live, for
example, the compiled functions which are already loaded in the world?
These objects live in the world load file.  But there's a catch:  they
can only live there as long as they are unmodified from the way they
were when the world was saved.  If an object is modified for any reason,
then it is given a new home in the paging file, so that the unmodified
copy of the object in the load file can be preserved for the next time
you boot.

What does this have to do with your question?  The answer is that GC
modifies all objects which are potentially garbage, and all objects
which point to potential garbage.  If any of these objects are in the
load file, then they will have to be moved into the paging file.  Thus
they take up memory that would have otherwise been available for
consing.

You can verify this yourself.  In the Show GC Status command before the
first GC, there will be X1 words of dynamic space, and Y1 words of free
space.  After GC, there will be X2 words of dynamic space, and Y2 words
of free space.  GC is successful, in that X2 < X1.  However, Y2 may be
more or less than Y1.  In fact, it is Y2 = Y1 + (X1 - X2) - M, where M
is the migration.

After the first GC, migration due to GC is zero.  There may be other
migration due to the programs running.

The reason GC doesn't take this into account is that it is expensive to
compute how big M will be, particularly since some migration will have
already occurred due to running programs.  It could be made less
expensive quite easily.  It's probably easier for me to fix than to
rewrite this explanation to the SLUG mailing list every three months.

Finally, I'll point out (again) some solutions:  (1) You can netboot.
When you netboot, the migration is exactly zero, so GC will perform as
you expect.  Additionally, you will have some additional disk space
available (equal to the number of pages which typically migrate).  (2)
You can run FULL-GC before saving your worlds.  FULL-GC will make some
objects static, meaning that they aren't anymore candidates for GC,
meaning they can't contribute to migration.  (3) If you're not already,
use Genera 7.2 or 7.3.  These releases include a number of system
features which minimize migration.