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

[Nicolas Bertolotti]

> > I actually made some experiments using the attached "ugly" patch which
> > does not really allocate both areas but basically ensures that the
> > card/cross map allocation succeeds after the heap is allocated.
> >
> > It consists in allocating enough bytes for the heap and the card/cross
> > map with mmap() each time a heap is allocated. Then, it immediately runs
> > remap() in order to release the bytes that correspond to the card/cross
> > map. The consequence is that, when it is necessary to allocate a new
> > card/cross map after that, it always works.
> >
> > I was wondering whether it would be possible to do something in the same
> > "spirit" rather than merging the heap and the card/cross map.
>
> Not all platforms have mremap (I believe we only use it on linux).  And I
> doubt that there is a guarantee that if you mremap from N bytes to M
> bytes, that you will necessarily be able to mmap N-M bytes.  Same
> thing goes if you munmap the N-M bytes.  I imagine that it would be less
> complicated to merge the heap and card/cross map.

Sure, and that is the reason why I call it an "ugly" patch.

Anyway, it was easy to implement and it works in my case. I use it in the mlton-compile binary itself in order to avoid those sporadic crashes when I cross compile my binaries but I don't plan to include it in the resulting binaries.

... 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.

Nicolas