[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: out of memory (resource control)



>>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).