[MLton] Crash fread(...) failed (only read 0) (Cannot allocate memory) during deepFlatten with MLton 20070826

[Matthew Fluet]

On Wed, 30 Apr 2008, Nicolas Bertolotti wrote:
> ... the merge definitely seems to be the only solution to ensure the 
> garbage collector is fully robust ... and my application has to be 
> robust. I'd like to spend some time working on the subject.
> - Any hint about how this could be implemented?
> - What about the secondary heap? It is not so clear for me what it is
>   used for ... and it does not seem to include its own card/cross map.

The only "hint" would be to move the struct GC_generationalMaps from the 
struct GC_state to the struct GC_heap and 'reinterpret' the mmap-ed 
memory for the heap as

  -------------------------------------------------------------------------
  |    old generation    |               |  nursery  | cardMap | crossMap |
  -------------------------------------------------------------------------
  |------oldGenSize------|
  |-----------------------size-----------------------|
  ^                                      ^           ^         ^
  start                                  nursery     cardMap   crossMap

Then it is just propagating this interpretation through...


The secondary heap is used as the to-space for major cheney-copy garbage 
collections; at the end of the GC, the secondary heap is swapped with the 
primary heap (swapHeapsForCheneyCopy).  It never holds live data while the 
mutator is running, and hence doesn't need its own card/cross map.  We try 
to hold on to a secondary heap (resizeHeapSecondary) so long as it doesn't 
cause paging and we can keep it as large as the primary heap.