Re: Larger GC thresholds for non-interactive Emacs

[Stefan Monnier]

> When we increase the threshold, free increases up to some value, but
> that value is limited by the underlying code:

A clarification: when you see

    [...]
    GC-898 p=1.0 total=18.7M free=7.3M thresold=18.7M
    GC-898 p=1.0 total=18.8M free=7.3M thresold=18.8M
    [...]

what it means is that after the first of the two GCs, the threshold
until the next GC was set at 18.7M, so when the next GC is called, the
heap has grown to at least 18.7M+18.7M=37.4M (possibly more), then GC
took place, it found 18.8M of live data and of the remaining ≥18.6M it
managed to return ≥11.3M back to the malloc library but it had to keep
7.3M as "free memory" because these are contained in malloc'd blocks
which still also contain *some* live data (typically, we malloc blocks
of say 16kB and then split them into the corresponding number of cons
cells, or floats, or strings, so we can only free a block of floats if
all the floats it contains are dead).

> In the first series of benchamarks with p=0.1 and total=18.8M, free is
> roughly equal to threshold.

This likely means that we basically neither called `malloc` in between
the two GCs (we instead managed to satisfy all the allocations from the
set of free objects we still had around) nor called `free` at the end of
the GC (because those 1.9M of free memory are spread around in such
a way that we can't return any of that memory to the malloc library).

The difference between the two cases is that when you have half of the
heap made up of dead objects, there's a higher probability that some of
those objects are clustered such that they make up a few complete
16kB blocks, whereas when only the dead objects represent only 10% of
the heap, almost all 16kB blocks will contain a mis of dead and live
objects and hence can't be returned to the malloc library.


        Stefan