Re: Languages don't matter. A mathematical refutation

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

"Brian Drummond" <brian@shapes.demon.co.uk> 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" <mailbox@dmitry-kazakov.de> 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.