From 839164c67217cd5b62dec08989386e102cac2ae4 Mon Sep 17 00:00:00 2001 From: Adam Sampson Date: Thu, 3 May 2018 20:51:35 +0100 Subject: [PATCH] Various corrections to chapter 22. 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 . --- md/language.md | 67 +++++++++++++++++++++++++++++++++----------------- 1 file changed, 44 insertions(+), 23 deletions(-) diff --git a/md/language.md b/md/language.md index 5649126..7a8b684 100644 --- a/md/language.md +++ b/md/language.md @@ -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 ` 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 ------------ - + ("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 ------------- -- 2.31.1