Re: [MLton] Crash in GC

On Tue, Nov 8, 2022 at 5:34 AM Chris Cannam
<[email protected]> wrote:
>
> On Mon, 7 Nov 2022, at 19:28, Matthew Fluet wrote:
> > So, you can see that with the default value of copy-generational-ratio
> > 4.0, the runtime will never do generational collection.  In the
> > absence of generational collection, the card marking doesn't matter
> > --- we're always doing a majorGC and tracing the whole heap.
>
> So when it is *not* intending to perform any minor GCs, does it partition the heap differently? e.g. half and half old-gen and nursery and then swap the two after a major GC?

If the generational GC isn't requested via the
copy-generational-ratio, then the nursery begins immediately after the
old-gen and allocation will proceed to fill the entire heap.  Then a
major copying collection will copy live data into a new heap.  When
major copying collection is used, then the heaps that are allocated
are either exactly half of fixed-heap or at most half of max-heap in
order to ensure that there is enough space for a to-space heap equal
in size to the from-space heap.

In the absence of fixed-heap and max-heap, I don't recall exactly the
policy.  (I.e., whether the heap is resized to bytesLive * live-ratio
or to 0.5 * bytesLive * live-ratio).

> Under what conditions does a mark-compact collection occur? Is that only when running out of heap space?

Both the generational and the mark-compact gc kick in when bytesLive
approaches RAM.  The basic heuristic is that a copying collection is
more efficient than mark compact (copying is proportional to the size
of the live data (which is hopefully a fraction of the whole heap,
though quite possibly not if the live data is approaching RAM size),
while mark-compact is proportional to the size of the entire heap
(live and dead data)).

> I see the reference to Sansom 1991 - I haven't managed to find a copy that isn't paywalled, but also it's perhaps for the best if I don't read around the subject *too* thoroughly or I might never get anything else done!

Hmm, it does seem that our Sansom link to CiteSeer is broken, but the
paper seems to be accessible at:
  https://citeseerx.ist.psu.edu/doc_view/pid/95b037dfc30a999d5a0326bc7a3eeeef21dfdc5a

There are a lot of knobs that one can turn on a garbage collector.  I
would like to rework MLton's gc controls to be a bit more generic and
allow them to be controlled from SML code as well.  Something like
`val MLton.GC.setFloatOption: string * real -> bool` and `val
MLton.GC.getFloatOption: string -> real option`, where the bool/option
would be used to indicate whether or not the string is recognized as a
GC control.