set-generation-2-gc-options &key minimal-size-for-gc allocation-increase-factor => prev-minimal-size-for-gc, prev-allocation-increase-factor
Previous setting of minimal-size-for-gc.
prev-allocation-increase-factor
Previous setting of allocation-increase-factor.
The function set-generation-2-gc-options sets internal variables that control when to automatically GC generation 2.
For both arguments, the value nil (the default) causes no change to the corresponding internal variable.
minimal-size-for-gc is used to set the minimum allocated bytes in generation 2 that will trigger an automatic GC of generation 2. The special value t is interpreted as most-positive-fixnum, and effectively blocks any automatic GC of generation 2. Integers up to 10000 are interpreted as a size in megabytes, while integers above 10000 are interpreted as a size in bytes.
allocation-increase-factor controls how large an increase (since the last GC) in the allocated bytes in generation 2 will trigger another automatic GC of generation 2.
After each GC of generation 2 (automatic or user invoked), LispWorks computes a value for gen-2-gc-threshold using the expression:
(max minimal-size-for-gc
(* (1+ allocation-increase-factor )
allocated-gen-2-bytes ))
where allocated-gen-2-bytes is the allocated bytes in generation 2.
The next automatic GC of generation 2 will be triggered only when the allocated bytes in generation 2 exceeds gen-2-gc-threshold in the future.
set-generation-2-gc-options also sets gen-2-gc-threshold to minimal-size-for-gc if it is non-nil (allocation-increase-factor has no effect on this setting).
The initial values are 64 megabytes for minimal-size-for-gc and 0.5 for allocation-increase-factor.
Setting a small threshold causes relatively frequent GCs of generation 2, which is acceptable if each GC is short enough that it does not bother the end user. That may be true if the total allocated (after a GC) in your application is only few 10's of megabytes. You should try to either time a GC of generation 2 by (time (gc-generation 2)) on the slowest device to which you target your application, or alternatively try to use the application on such a device with the small threshold settings and see if you notice unacceptable delays.
A small threshold probably reduces the efficiency of the application a little, but has some advantages:
Therefore, if the delays are not long enough to be annoying then it is probably a good idea to have a low threshold.
By contrast, a large threshold causes less frequent GCs of generation 2, which normally causes it to grow more before a GC occurs. As long as LispWorks can get all the memory it needs to perform a copying GC, the time taken to do a GC correlates to the amount of memory that is still alive after (rather then before) the GC. Thus if generation 2 contains mainly "generation leak" objects (see Preventing/reducing GC of generation 2) that are removed by the GC, then each GC would take approximately the same time regardless of how frequently GC occurs. In that situation, doing a GC less frequently results in less time overall. However, if LispWorks fails to get memory from the operating system to do a copying GC, then the GC is done partially by a marking GC, which is slower and less effective. Thus you do not want to increase the threshold "too much". A copying GC needs to increase the memory size by approximately the current amount allocated, but it is difficult to predict how much memory the operating system is ready to give at any point, and it depends on the hardware and operating system. It is therefore difficult to say how much is "too much".
LispWorks User Guide and Reference Manual - 20 Sep 2017