[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: out of memory (resource control)
- To: firstname.lastname@example.org
- Subject: Re: out of memory (resource control)
- From: email@example.com
>>about the "superiority" of one system to another. i didn't really take it that way, since it raised quite a serious point. >> then the answer is that it was the intended behavior, and the system >>should be "tuned" to any particular solution. i wouldn't go as far as to say whether exactly what happened in your case was `intended' or not: it depends on how and where it crashed as to how `intended' the particular behaviour was in emu. emu and the native Inferno kernel internally attempt to reflect errors back to the application level when possible, and die with dignity when it's not, but a check might have been left out. i was really trying to point out that the resources are, in practice, in most cases, ultimately finite, and especially in embedded applications you want to avoid starting what you can't finish. i'd also say there's an important distinction between resources that implement a language's virtual machine (specifically memory and CPU), that sit below the level of the language, and those that are visible at the surface. most resource allocation failures can be dealt with directly (and as gracefully as possible) within a Limbo program: failing to get a network connection, bumping into a limit on some system software resource, etc., because it will see, for example, an error return from a system call. the Inferno kernel takes care to pass the errors back. the problem with two other resources -- CPU and memory -- is that they are allocated on the Limbo program's behalf by the Inferno kernel and the Dis interpreter, and happen `inside' a Limbo operation, below the level of the programmer's virtual machine. for instance, although one could have `ref' return nil, like C's malloc, when memory is exhausted, it doesn't really solve the problem in Limbo: many other operators (eg, slicing and string operations) allocate memory on the program's behalf, and those would need to be caught somehow. furthermore, the failure is a function of the activity of the whole system (other processes take time and allocate memory), operating concurrently. i'm not sure what the Inferno/Limbo designers had in mind (i'm just a happy developer) but here are my thoughts. some systems/languages provide an exception mechanism in the language to signal these things. based on admittedly limited experience with Ada, i'm not sure adding exceptions really deals with it well. it seems to be very hard to reason about the state of the system following an exception, especially when it has happened `inside' a language operator. the safety critical embedded systems i know that are written in Ada use only one exception handler at the outermost level (`when others'), and it typically reinitialises the system. instead, they use design techniques and static analysis to ensure that the exception ``can't happen''; that single exception handler is there only as a last-ditch attempt to recover from a failure of verification or validation. in Limbo, one could probably do as well by destroying the failing Limbo process and letting a monitor process in the application take recovery action. in native Inferno embedded applications, my view is that it is better to budget sufficient memory and CPU ahead of time based on peak expected load, and if necessary refuse offered load, much as the telephone system tries to do. of course, we'll need appropriate design/analysis tools and data to do so in general. a common technique is to allow much more memory and a faster CPU than might strictly be required for an embedded application, but it can be expensive. i can see a need for Limbo design and analysis tools, performance measurement, ... all the usual things to allow accurate budgets to be determined (and checked).