Re: [9fans] Google search of the day

["Douglas A. Gwyn" <DAGwyn@null.net>]

erik quanstrom wrote:
> as was discussed a few months ago, any system that has unreserved
> stack allocation can suffer from similiar problems.  the oom killer
> on linux is a symptom of this kind of problem.

Speaking of such things:

(1) Linux had/has a "feature" where the storage reserved by
malloc/sbrk may be over-committed, so that despite a "success"
indication from the allocation, when the application gets around
to using the storage it could suddenly fail due to there not
being enough to satisfay all current processes.  I urged (but
don't know whether anybody listened) that overcommitment should
be disabled by default, with processes that want it (said to
include "sparse array" programs, which sounds like bad design
but that's another issue) being required to enable it by a
specific request, or at least flagged as special in the
executable object file.  I kludged around this in my portable
malloc implementation by having a configuration flag which if
set caused malloc to attempt to touch every page before
reporting success, trapping SIGSEGV in order to maintain
control.

(2) C, as well as many other PLs, has always had a problem in
that there is no clean, standard mechanism to handle the
situation in which a function invocation finds insufficient
stack remaining to complete the linkage (instance allocation).
This is especially problematic in memory-constrained apps such
as many embedded systems, when the algorithm is sufficiently
dynamic that it is impossible to predict the maximum nesting
depth.  At least with malloc failure, the program is informed
when there is a problem and can take measures to cope with it.

I hope people working on run-time environments will find ways
to do better.