Re: Dynamic allocation in the predefined language environment

["Randy Brukardt" <randy@rrsoftware.com>]

"Bob Duff" <bobduff@theworld.com> wrote in message 
news:87fv4zvbsf.fsf@theworld.com...
> Matthias-Christian Ott <ott@mirix.org> writes:
...
>> If you follow the strong exception safety principle from C++, corrupted
>> data structures should not be a problem.
>
> I don't see how.  Storage_Error as defined by the language is like an
> asynchronous interrupt.  When programming with asynchronous interrupts,
> you need a way to disable interrupts in usually-short sections of code.
> When programming with Storage_Error, you need a way to "disable" running
> out of memory.  Ada lacks such a feature (and so does every other
> programming language I know).

It's hard to imagine how any programming language (or language 
implementation) could protect against running out of memory. At best, one 
can try to contain the damage, but the usage/availability of memory is 
pretty much out of the hands of the implementer (unless they're targeting a 
bare machine).

>>...However, you can only do this
>> in code that is under your control.
>>
>> You can somewhat avoid Storage_Error exception while handling
>> Storage_Error exceptions by having "spare" memory that you free directly
>> after the exception handler is invoked.
>
> Yes, but Storage_Error is raised when running out of stack memory as
> well as heap/pool memory.  Stack memory is the more "interesting" issue,
> IMHO.  Imagine a "when Storage_Error" handler that simply prints a
> message "Memory exhausted while processing line N of the input".
> No heap-allocation involved, but in theory it can still raise
> Storage_Error.

Indeed, it often does -- Put_Line is relatively expensive in terms of stack 
and/or heap memory.

On our old 16-bit compilers, the stack for the environment task and the heap 
grew together -- that way, we could maximize the use of the address space - 
no fixed size was needed for either the stack or the heap. The net effect 
though was that when you ran out of memory it was *all* gone. We had a lot 
of trouble with the exception handling mechanism itself failing because of a 
lack of memory, and when we fixed that, only the memory freed by unwinding 
the stack was available -- depending where the handler was, that might not 
have been much.

We added a one-time hack to the runtime to make that a bit less of a 
problem -- we added a "leeway" setting that triggered Storage_Error a bit 
too early (if the distance between the top of the heap and top of the stack 
(stacks growing downwards on Intel machines) is less than Leeway, then 
Storage_Error is raised), and the setting was decreased after the first 
triggering of Storage_Error. Of course, that only works once; it's hardly 
worthwhile for programs that run a long time (like a web server).

So Storage_Error handlers are a crap-shoot. I recall one Ada person (Dave 
Emery, I think) saying the Storage_Error is like a parachute that opens on 
impact -- it works, but it's very useful.

Our compiler has a handler for Storage_Error:

    when Storage_Error =>
        J2Error.Fatal_Error (128);

which is supposed to report the error and then clean up. But it almost never 
works because there usually isn't enough memory to do the file operations 
that are used by the error handler and the clean-up that follows. Luckily, 
modern hosts rarely run out of memory during a compile (that used to be a 
common problem on CP/M and MS-DOS).

The best Storage_Error handlers do as little as possible to recover (or 
report), because most likely you are in deep trouble. Depending on the 
compiler's memory model and how your program is structured, it may be 
impossible to get out of it.

                                  Randy.




>>...Otherwise there are many
>> application-specific possibilities on how to deal with memory allocation
>> errors in a spectrum ranging from simply aborting to degradation of
>> service/user experience.
>
> - Bob