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.
