[MLton-devel] very unfortunate behavior when profiling allocations

[Stephen Weeks]

> My notion before, which I would think would still be good, would be
> to simply make out-of-memory be an exception.  The notion is that
> when you get to the first handler, you get to GC what was alive
> before but isn't now.  If there isn't enough memory for the handler
> then the exception would be raised in it, etc.

It would be nice to raise a "LowMemory" exception.  The reason I use
"LowMemory" instead of "OutOfMemory" is that I can see setting a GC
parameter that causes the exception to be raised if the heap residency
is >= some percentage.  I also agree that it has potential to work
because of the additional heap objects that become unreachable as
stack frames are eliminated.

Here are the difficulties in implementing this.

1. It belongs in the RSSA IL after limit check insertion, which
inserts the calls to GC_gc.  That means that the SSA optimizer must
somehow know about these implicit exceptions.  This is problematic
because at present the SSA optimizer assumes it has complete
information about raises and handles.  Furthermore, it eliminates
handlers that aren't wrapped around an function calls that may raise.
The SSA optimizer will also have to make some kind of conservative
approximation about which functions may allocate, so that it can
conservatively know which functions may raise.

2. Any C call that mayGC must now be able to return some error
condition indicating LowMemory.  This return condition must be checked
upon return from such C calls.  Presumably, a pass that runs on RSSA
after limit check insertion could insert these checks.

3. The check after a C call must be able to raise to the correct
handler.  This requires preserving extra handler information
throughout the SSA optimizer for anything that might turn into a C
call that can raise.

> A more conservative extension would be to have a ML atExit which
> would be the only handler to try the above.  A problem with this is
> that you often, in C, know and depend on the fact that the atExit
> code is NOT run if you abort.

I'm not sure what you mean here.


Overall, I think this a good idea.  I'm just not confident that I have
a good design and would like some more design discussion before I
start implementing.

In the meantime, since I'd like to get a release out in the next week
or two, I think I'll do the simple change for profiling.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel