[MLton-devel] yeah, that did the trick

[Matthew Fluet]

> During collection the GC will allow itself to have two spaces mmapped
> whose total usage is much more than RAM size.  However, one of the
> spaces will be new -- it is the "to space" of a copying collection and
> not all of the space will be touched during GC, only as much as is
> needed to copy live data will.  Once the GC is finished, the "from
> space" will be munmapped.  This shouldn't cause paging.
> 
> If you are seeing lots of paging, that is bad and shouldn't be
> happening.

I'd like to point out that the MLton runtime works under the assumption
that it is not competing with other programs for RAM.  That is, MLton
computes ram = (ramSlop) * (totalRAM) at the start of the program, where
ramSlop is by default 0.8, but configurable via a runtime command
line argument like: "foo @MLton ram-slop 0.9 --", and assumes that if the
active set of memory pages fits in ram, then it won't page.  If you
violate that assumption, say by running some other program that has a
large active set of pages, or if the FreeBSD kernel requires more than
20% of your total RAM (doubtful?), then you will most certainly see lots
of paging.



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel