Re: Languages don't matter. A mathematical refutation

[Brian Drummond <brian@shapes.demon.co.uk>]

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.

>>> 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.