[MLton] Segmentation fault in 32 bit mode on a 6 GB machine with ram-slop 0.85

[Vesa Karvonen]

On Tue, Nov 4, 2008 at 12:09 PM, Nicolas Bertolotti
<Nicolas.Bertolotti at mathworks.fr> wrote:
>> Managing memory between processes isn't really MLton's job, but the
>> user's. Don't run two programs who need more combined memory than you
>> have. :-) Or set ram-slop 0.5.
>
> Yes and no. It is the user's job but MLton could make it easier.
>
> I would like to be able to monitor the allocations that are made by my processes and
> communicate with them in order to change some runtime parameters and/or force one
> process to page its heap to the disk and sleep.

Being able to (better) monitor allocations and change some more
runtime parameters programmatically could be useful.  However, the
ability to communicate with a running MLton process and send commands
to it seems rather specialized and potentially dangerous and unsafe.

Given interfaces for accessing the allocation information and changing
runtime parameters, it shouldn't be too difficult to implement a
simple monitoring server in SML.  I've written two experimental
libraries that could be used for a purpose like that although neither
is probably currently a perfect fit for your needs.  One is the
Program Variable Editor (var-ed)
(http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/org/mlton/vesak/var-ed/unstable/).
 Another is the RPC library (rpc-lib)
(http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/org/mlton/vesak/rpc-lib/unstable/).
 If you take a look at them, feel free to suggests
changes/improvements especially if those could then serve your needs.

> In order to achieve this, I don't have any other solution than to hack MLton. Having a
> well defined interface for that would be helpful (unfortunately, maybe just for me)

I think that adding some more functionality, where possible, to the
MLton.GC (http://mlton.org/MLtonGC) structure, such as finding out the
heap size, would be a good thing.  OTOH, a process monitoring server
should be implemented in the SML program rather than by MLton, IMO.

-Vesa Karvonen