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: border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Sun, 5 Apr 2015 09:55:55 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <87h9t95cly.fsf@jester.gateway.sonic.net> <04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com> <87oan56rpn.fsf@jester.gateway.sonic.net> <877fts7fvm.fsf@jester.gateway.sonic.net> <87twwv66pk.fsf@jester.gateway.sonic.net> <32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net> <87pp7j62ta.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 5 Apr 2015 09:55:55 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="da745e888d4a5182b5fda6212bbb0a63"; logging-data="28703"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+yXwVt1hb2sGtQO87d+a21LR2drQehyEM=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:MRUOX7t6SrzGGUfVbCdYQqziZko= Xref: number.nntp.giganews.com comp.lang.ada:192738 Date: 2015-04-05T09:55:55+00:00 List-Id: On Sun, 05 Apr 2015 10:00:46 +0200, Dmitry A. Kazakov wrote: > On Sat, 04 Apr 2015 13:44:49 -0700, Paul Rubin wrote: > >> "Dmitry A. Kazakov" writes: >>> In Ada memory management is automatic >> >> Do you mean something other than stack allocation and "new"? > > Stack Also storage pools, though you might call that a semi-automatic memory management system. >>> having it non-testable eliminates all means of quality assurance. End >>> of story. >> >> I don't think that's right. Being unable to statically analyze GC >> means you can't prove your program will never crash from memory >> exhaustion. In avionics, that may be intolerable and you better not use >> GC. In other areas (example: compilers), you may care more that your >> program never computes a wrong result than that it never crash, so if >> after reasonable testing it doesn't seem to have memory leaks, you are >> fine and GC is great. > > It is an especially interesting example because exactly GNAT or GCC, > don't know which of them, has a huge problem with memory consumption. I > don't say it is because of GC [**], but it is the problem you said > irrelevant, which makes it sometimes impossible to compile Ada program > at a 32-bit system. I suspect gcc, having seen the same phenomenon with versions of ghdl that use gcc as an optimising back-end. Some machine-generated VHDL programs (like gate-level netlists) would compile and simulate easily with ghdl's own JIT compiler, but blow up in gcc's optimisation passes, unless these were turned off completely. We're talking about source files of a few million lines, that (in some optimisation passes) consume many GB and either crash (if you're lucky) or eat all your swap space (if you're not). > ** Most compilers use arena pools for data structures. It would be > insane to deploy GC there, IMO. Not only does gcc use GC, it buries most of the GC source code in the object code directories, making it harder to find. (This code is auto- generated by shell scripts and awk scripts and the like, trawling the actual source code for object definitions. It's a fruitful source of head- scratching if, like me, you're not a gcc expert, and "grep variable_name" in the source tree returns a blank. Especially when the scripts aren't re- run leaving the GC code out of sync with the source) -- Brian.