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!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Mon, 6 Apr 2015 16:27:35 -0500 Organization: Jacob Sparre Andersen Research & Innovation 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> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1428355656 26077 24.196.82.226 (6 Apr 2015 21:27:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 6 Apr 2015 21:27:36 +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:25444 Date: 2015-04-06T16:27:35-05:00 List-Id: "Brian Drummond" wrote in message news:mfr0rb$s0v$1@dont-email.me... > 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. Especially true if you are using subpools. You forgot containers. One of the most important purposes of the container packages is that they can take over the memory management (especially useful for indefinite types, like class-wide types). That means that one can build complex data structures but yet treat them for memory management purposes as if they are stack allocated. For instance, an expression tree in a compiler can be made up of tagged nodes for the different kind of expression parts (operators, memberships, conditionals, allocators, etc.), and the tree can be stored in a tree container. Thus, no explicit memory management is needed to deal with tree temporaries and the like (and you really don't need any management for global trees [ones like default expressions and the like that get stored in the symboltable], as they never get freed until the end of the compilation). Yes, the implementer has to create the memory management used to implement the containers, but the same is true for garbage collection. And the former is a lot easier to get right than the latter. IMHO, the order of memory management preferability goes approximately as follows: (1) Stack-based (in Ada, this includes dynamically-sized objects, such as an array whose length depends on a parameter; this probably isn't implemented with a traditional stack, but the compiler will do the management). (2) Container-based. (discussed above). (3) Finalization-based. (Using a controlled wrapper of some sort; deallocate on finalize. Smart pointers fall into this category. The only reason that these fall below (2) is that these are user-defined, meaning there is a higher possibility of errors. [Implementers make mistakes, but there are more people using there stuff so they don't last as long.]) (4) Subpool-based. (Sometimes called "arenas"; this is a semi-automatic mechanism in that all items of a group are freed together.) (5) Manual allocate/deallocate (with or without storage pools). Garbage collection probably helps with (5) [few programmers are good enough to do that correctly all of the time]; there might be an argument that it is better than (4) [I doubt it, because the overhead is so much worse, but at least that's open to debate.] Whether GC is better than (3) depends on the quality of one's programmers; if they know enough to use existing libraries rather than rolling their own (or at least copy from existing designs), then (3) is a clear win over GC. GC might be an advantage to a naive team, but I'd rather they stay far away from any software. ;-) GC has nothing to offer for (1) and (2), and in some cases might even be harmful (by covering up bugs, as pointers to stuff that ought to be dead still exist and appear to work). Anyone that thinks that Garbage Collection is something required hasn't thought enough about how memory management can be done better. Indeed, it seems to foster terrible programming practices because it's "easy"; for example, Firefox doesn't seem to release memory until a tab is closed, then not then until a decent amount of time afterwards. It has no problem going catotonic from running out of memory (and the reason it hangs is that the GC thrashes). Randy.