Various corrections to chapter 22.
authorAdam Sampson <ats@offog.org>
Thu, 3 May 2018 19:51:35 +0000 (20:51 +0100)
committerJason Self <j@jxself.org>
Fri, 4 May 2018 02:36:28 +0000 (19:36 -0700)
There were several changes between the 54/104 and 55/105 manuals in this
section that weren't marked with change bars, including a couple of new
paragraphs of text describing the arguments to <GC>.

md/language.md

index 5649126c82c8ac65521f49427424306b42bdf31e..7a8b684274a250efdcfcaa81595794e78952f2d8 100644 (file)
@@ -8399,9 +8399,9 @@ when space becomes full varies, as discussed below.
 
 Most storage used explicitly by Muddle programs is obtained from a
 pool of free storage managed by a "garbage collector". Storage is
-obtained from this pool by the `SUBR`s which construct objects. When a
-`SUBR` finds that the pool of available storage is exhausted, it
-automatically calls the garbage collector.
+obtained from this pool by the `SUBR`s which construct objects. When
+such a `SUBR` finds that the pool of available storage is exhausted,
+it automatically calls the garbage collector.
 
 The garbage collector has two algorithms available to it: the
 "copying" algorithm, which is used by default, and the "mark-sweep"
@@ -8430,7 +8430,7 @@ Only when the total system resources are exhausted will you finally
 lose.
 
 Thus, if you just "forget about" an object, that is, lose all possible
-means of referencing it, its storage is automatically reclaimed.
+means of referencing it, its storage area is automatically reclaimed.
 "Object" in this context includes that stack-structured storage space
 used in `PROCESS`es for functional application.
 
@@ -8555,8 +8555,9 @@ becomes full, Muddle goes through the following procedure:
 5.  Finally, the "mark-sweep" algorithm sweeps through the storage
     space, adding unmarked objects to the internal free lists for
     later re-use. The "copying" algorithm maps the inferior process's
-    address space into Muddle's own, replacing old garbagey with the
-    new compact storage, and the inferior process is destroyed.
+    address space into Muddle's own, replacing old garbagey storage
+    with the new compact storage, and the inferior process is
+    destroyed.
 
 22.5 GC
 -------
@@ -8565,24 +8566,44 @@ becomes full, Muddle goes through the following procedure:
 
 causes the garbage collector to run and returns the total number of
 words of storage reclaimed. All of its arguments are optional: if they
-are not supplied, a call to GC simply causes a "copying" garbage
+are not supplied, a call to `GC` simply causes a "copying" garbage
 collection.
 
 If *min* is explicitly supplied as an argument, a garbage-collection
 parameter is changed permanently before the garbage collector runs.
 *min* is the smallest number of words of "free" (unclaimed, available
 for use) movable garbage-collected storage the garbage collector will
-be satisfied with having after it is done. Initially it is 8192 words.
-If the total amount of reclaimed storage is less than *min*, the
-garbage collector will ask the operating system for enough storage (in
-1024 word blocks) to make it up. N.B.: the system may be incivil
-enough not to grant the request; in that case, the garbage collector
-will be content with what it has, **unless** that is not enough to
-satisfy a **pending** request for storage. Then it will inform you
-that it is losing. A large *min* will result in fewer total garbage
-collections, but they will take longer since the total quantity of
-storage to be dealt with will generally be larger. Smaller *min*s
-result in shorter, more frequent garbage collections.
+be satisfied with having after it is done each time. Initially it is
+8192 words.  If the total amount of reclaimed storage is less than
+*min*, the garbage collector will ask the operating system for enough
+storage (in 1024-word blocks) to make it up. N.B.: the system may be
+incivil enough not to grant the request; in that case, the garbage
+collector will be content with what it has, **unless** that is not
+enough to satisfy a **pending** request for storage. Then it will
+inform you that it is losing. A large *min* will result in fewer total
+garbage collections, but they will take longer since the total
+quantity of storage to be dealt with will generally be larger. Smaller
+*min*s result in shorter, more frequent garbage collections.
+
+*exh?* tells whether or not this garbage collection should be
+"exhaustive". It is optional, a `FALSE` by default. The difference
+between normal and exhaustive "copying" garbage collections is whether
+certain kinds of storage that require complicated treatment (for
+example, associations) are reclaimed. An exhaustive garbage collection
+occurs every eighth time that the "copying" algorithm is used, or when
+`GC` is called with this argument true, or when a normal garbage
+collection cannot satisfy the storage request.
+
+*ms-freq* gives the number of times the "mark-sweep" algorithm should
+be used hereafter for every time the normal "copying" algorithm is
+used. Giving `0` for *ms-freq* means never to use the "mark-sweep"
+algorithm, and giving `<CHTYPE <MIN> FIX>` means (effectively) always
+to use it. The "mark-sweep" algorithm uses considerably less processor
+time than the "copying" algorithm, but it never shrinks the
+free-storage pool, and in fact the pool can become fragmented. The
+"mark-sweep" algorithm could be useful in a program system (such as
+the compiler) where the size of the pool rarely changes, but objects
+are created and thrown away continuously.
 
 22.6. BLOAT
 -----------
@@ -8623,8 +8644,8 @@ by default), and indicate the following:
     `READ`ing large `STRING`s, and calling routines within the
     interpreter and compiled programs)
 
-Arguments on the second line are also `FIX` and optional, but they set
-garbage-collection parameters permanently, as follows:
+Arguments on the second line above are also `FIX` and optional, but
+they set garbage-collection parameters permanently, as follows:
 
 -   *min*: as for `GC`
 -   *plcl*: number of slots for `LVAL`s added when the space for
@@ -8693,7 +8714,7 @@ about certain areas of storage. In detail:
 22.8. GC-MON
 ------------
 
-    <GC-MOND pred>
+    <GC-MON pred>
 
 ("garbage-collector monitor") determines whether or not the
 interpreter will hereafter print information on the terminal when a
@@ -8719,7 +8740,7 @@ of `GIN` and `GOUT`.
 Two `SUBR`s, described next, use only part of the garbage-collector
 algorithm, in order to find all pointers to an object. `GC-DUMP` and
 `GC-READ`, as their names imply, also use part in order to translate
-between Muddle objects and binary representation thereof.
+between Muddle objects and binary representations thereof.
 
 ### 22.9.1. SUBSTITUTE
 
@@ -8734,7 +8755,7 @@ the few legitimate uses for it is to substitute the "right" `ATOM` for
 the "wrong" one, after `OBLIST`s have been in the wrong state. This is
 more or less the way `ATOM`s are impurified. It is also useful for
 unlinking `RSUBR`s. `SUBSTITUTE` returns *old* as a favor: unless you
-hang onto *old* at that point, it will be garbage-collected.
+hang onto *old* at that point, it will be garbage.
 
 22.9.2 PURIFY
 -------------