[MLton-devel] GC question

[Henry Cejtin]

Sorry, you are write that the queue is in to space, but it is only one more
sequential access.  Yes, this is what I thought was the idea of the disk:
You do the same accesses to from space as you would if it were a normal GC,
but the writes to to-space becaome writes at the end of the file, and the
reads of to space are on sequential pass.  When the copying is done, you
do a second pass reading the file, again sequentially, into what used to be
the from space, with it serving as the to space now.  Sounds amazingly cheap
to me.  In Linux, if you fit in memory then the write and 2 reads will all be
to the disk cache.  I would bet that if you then do the ftruncate() system
call that the data will NEVER be written to disk.  I wouldn't be surprised
that in this case it only slows GC time down by a factor of 2 or 4, and it
works fine when you get larger (until live + slack doesn't fit in RAM).
Isn't this what you had in mind, or were you thinking of using the disk with
the fancier in-place compaction?  No, then I don't see any use for the disk.

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel