From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dynamic allocation in the predefined language environment Date: Fri, 10 Jul 2015 16:58:49 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <559a623d$0$293$14726298@news.sunsite.dk><873811cre5.fsf@theworld.com><559a8d12$0$297$14726298@news.sunsite.dk> <559a936c$0$292$14726298@news.sunsite.dk><87twthbaia.fsf@theworld.com><559b9160$0$297$14726298@news.sunsite.dk><87fv4zvbsf.fsf@theworld.com> <87bnfmuzl0.fsf@theworld.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1436565530 30334 24.196.82.226 (10 Jul 2015 21:58:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 10 Jul 2015 21:58:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:26754 Date: 2015-07-10T16:58:49-05:00 List-Id: "Bob Duff" 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.