On Tue, 28 May 2002, Jerome Vouillon wrote: > That's an interesting point, actually. What is the right thing to do > when we run out of memory? > - Abort immediately. > This is not very user-friendly. > - Return a special value. > But then we need to check the return value of almost all functions > (including string_compare, for instance).
I personally dislike this approach, as it requires a large amount of programming discipline from everyone who works on the project. The current code indicates that if we took this approach, we would spend quite a bit of time squashing bugs from not checking return values in wierd places. It probably also hurts common-case performance to litter your code with redundant null-checks as well, but I don't have any data. > - Instead of returning a special value, we can set a global variable > to signal the error. > Again, we need to check this variable everywhere. This by itself seems worse than the above, since it makes problems even easier to ignore. > Note that this is the solution adopted by Java. Last time I wrote in Java, errors were entirely exception-based. Have things changed because of the locking issues you mention below? > - Raise an exception using longjmp. > But then, if we start using locks all over the place like in Java, > we are pretty sure to leave the program in an inconsistent state. We're currently lock-free, which makes this sound like a good option. > - Use a small amount of emergency memory to invoke a user-defined > handler which can either release some memory or signal the problem > to the user. I worked on some code that had something like this for memory allocation, and found it worked well. If malloc failed, the code would call a handler which free()d a chunk of emergency memory grabbed on startup, and set a global "we're low on memory" flag. Then it would retry the allocation, and exit if it failed. Whenever memory was reclaimed, the system would check to see if it had freed the emergency chunk, and if so, try to reallocate it and clear the flag. The global low-mem flag could then be used to try to reduce overall memory use. > But how much emergency memory is enough? 64k? There will certainly be pathologically large allocations for which we can never have enough, but it seems like we could experiment until we found a size that gives us enough time to recover or exit gracefully. /s
