Re: Dynamic allocation in the predefined language environment

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

"Bob Duff" <bobduff@theworld.com> wrote in message 
news:87bnfmuzl0.fsf@theworld.com...
...
> Here's what I have in mind: The programmer may mark a procedure (or
> region of code?) as "doesn't run out of stack memory".  The
> implementation calculates a worst-case (compile-time-known) stack usage
> for that procedure (including everything it calls that has the same
> property).  This is always possible, because it can never be bigger than
> the size of the address space.

Interesting.

...
> This wouldn't fit in well with the usual Ada compilation model,
> which wants to generate code without looking at the transitive
> closure of the call graph.  I can think of various designs,
> suitable for a from-scratch compiler implementation -- I
> wouldn't want to retrofit this feature into an existing
> compiler.

You could implement it rather like inlining. The effect would be the same.

For Janus/Ada, which aggresively tries to avoid unnecessary dependence on 
other units (the primary reason we used generic code sharing, for example), 
this would be a lousy model. But one could argue that such avoidance isn't 
as necessary as it once was.

Or one could use link-time fill-ins of the memory sizes in the pre-checks 
(that would be much more in keeping with Janus/Ada). Anyway, I agree: not 
that easy to retrofit.

...
>> 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).
>
> I don't see why it should work only once.  You reserve enough stack
> space so that S_E can be raised.  The "raise S_E" uses that reserve,
> then when it jumps to the handler, the reserved space is again
> reserved.

The extra space is needed so that the handlers execute without raising S_E 
(mainly so Put_Line would work). We don't have any runtime call at the end 
of handlers (they return using the normal subprogram mechanism), so there 
isn't any sensible way to know when to reset the leeway value. I spent a 
looonnnngggg time thinking about this problem before I gave up (adding 
runtime overhead to fix that was a non-starter).

[For instance, I considered using the next registration of an exception 
handler to reset the leeway. But that didn't work because the handler could 
call something that uses an exception handler internally. Indeed, Put_Line 
does that, so that didn't work at all.]

...
>>...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.
>
> ;-)
>
> I'll assume a missing "not" there.

Yup. Too fast writing CLA messages, I guess.

> Anyway, it's better than languages that allow running out of stack to
> overwrite arbitary memory locations (like stacks belonging to other
> tasks).

Surely.

                   Randy.