Walter Bright wrote:
I asked this over on stackoverflow.com to see what people using other
languages have to say, as well as the D community. The reason I ask is
to see if memory allocation can be allowed in functions marked "nothrow".
http://stackoverflow.com/questions/333736/is-out-of-memory-a-recoverable-error
It seems that D has (or rather, can have) a trivial solution to this
problem. Allow programs to register with the GC when they have memory
which can be easily freed (caches and such). Then you can make "out of
memory" a non-recoverable error, since it only hits when we fail to
recover enough.
It seems to me that there are 3 different types of callbacks that can be
registered: pre-scan, post-scan, and crisis.
PRE-SCAN
Before the mark & sweep runs, *every one* of these callbacks is called.
These are for things which the program can give up with very little
cost, such as emptying free pools in allocators. Since this happens
before the scan, you do *not* have to use explicit "delete"s; you can
just drop references as normal. After all of these callbacks are
called, the mark & sweep runs, and we hope that it will find some
newly-discarded regions.
POST-SCAN
This is for things which we typically don't want to give up, but which
we might relinquish if the only alternative would be getting more memory
from the OS. For instance, caches of things read from disk. In this
case, callbacks must explicitly delete things (since the scanner has
already run). The GC will call each of these in turn, but will stop if
and when enough (contiguous) memory is freed to perform the allocation
that the GC is trying to perform. If the GC goes through the entire
list without finding enough, it will ask the OS for more memory.
CRISIS
This is a set of callbacks which represent things which we would only
discard in a true crisis, such as caches which would be time-consuming
to rebuild. These are called only if the OS refuses to give us more
memory. Again, you have to explicitly delete, and the GC will stop
calling if and when it finds enough free memory.
Seems to me that with this mechanism in place, we can treat
out-of-memory as an unrecoverable error.
Thoughts?
P.S. It would be nice to also have callbacks that were called when the
OS started page swapping, or callbacks to deal with fragmentation. But
that is something to consider some other time...
