Re: newbie Q: storage management

["Samuel A. Mize" <smize@magellan.bgm.link.com>]

Jon S Anthony wrote:
> In article <336754A0.41C6@magellan.bgm.link.com> "Samuel A. Mize" <smize@magellan.bgm.link.com> writes:

Please note that I was trying explain the reasoning behind unchecked
deallocation, which was designed for Ada 83, not Ada 95.  If that
was unclear, I apologize.  The design decision was carried over into
Ada 95 by (1) the vocal minority who fear dynamic memory usage,
(2) the requirement for upward compatibility, and (3) inertia.  (See
also below about "special needs annexes" before flaming.)

As Jon write in another post:
> Basically, this asymmetry is there because the designers did not think
> they could "require" GC (at least at the level of the high expectation
> of it for things like Lisp, Eiffel, ST, etc.) because many of the
> target areas of use would not need (or even require _not_ having) GC.

That's it exactly.  I was just trying to fill in some of the
ideas behind people requiring _not_ having GC, in the 1977-1983
time frame.


Regarding unchecked deallocation, Jon quoted me:
> > What this does is implementation dependent -- if memory reclamation
> > is required, it's the responsibility of the programmer (or code
> > reuser) to ensure that the implementation (that is, by the compiler
> > and run-time system) reclaims memory as necessary.
> 
> How can this be the responsibility of the application programmer?

The same way it's the programmer's responsibility to make sure
that the implementation supports the Distributed Annex when writing
code that requires it.

More specifically, I guess, it's the responsibility of whoever
procures the compiler.

The point is just that there isn't an onus on all implementations
to reclaim memory when it's freed.


> Also, the effects of UC are pretty well laid out in 13.11.2 and while
> reclamation is implementation dependent (?!?!) I would think any
> implementation not providing it for the standard storage pool would be
> sorely broken.  Unusably broken.

True for most applications.  The requirements were written so that a
vocal minority could get validated compilers.  (In all fairness,
they were the supposed target group for the language, originally.
Ada rapidly evolved to serve a larger audience.)

For Ada 95, 13.11.2(10) says that after unchecked deallocation
"their storage can be reused for other purposes" but this stops
short of explicitly requiring it to be made available for later
dynamic allocation.  If it required reclamation, 13.11.2(17) would
be meaningless.  ("For a standard storage pool, Free should actually
reclaim the storage." -- but implementation advice, not a
requirement.)

So, we two and the standard agree that a non-reclaiming implementation
would be marginal at best.  But, it could validate, and would be useful
-- even critical -- to a small minority.


> > If reclamation were in the language, embedded systems builders could
> > just avoid it, but compilers targeted to the embedded-system market
> > would still have to include it to be validated.  This adds cost and
> > complexity to the compiler, and adds size to the run-time code that
> > gets loaded along with the user code.
...
> I suppose you would really be against GC.

No, not at all.  The poster asked about the reasons for a decision,
and I explained them as best I understood the reasoning of the
language designer (I don't see Mr. Ichbiah posting here, or I'd
let him speak for himself).

I tried to indicate that it was not necessarily a consenus in the
computing community, but I didn't state that explicitly.


>I don't know why people
> keep saying this.  How is this in any way different from any other
> specialized needs annex sort of thing???


I was talking about the original design decision, which was made
for Ada 83, when things were either included or not.  I forgot our
general c.l.a rule that "Ada" refers to Ada 95.

The specialized needs annexes are a great boon, and there are
several I'd like to see defined.  Maybe there could be created a
working group for interim/proposed annexes.  They need to be
written down, debated, and tested out, just like Ada 95 was.
Many of the problems that Ada 95 fixes would never have gotten
INTO Ada 83 if it had gone through the test/eval cycle they used
for Ada 95.  (Thanks, Mr. Taft!)

For all I know, maybe there IS such a group at the ANSI or ISO
level.  Anyone know, or know how to start such a thing?  If not,
is anyone else interested in a project to consider different
language extension proposals (formally or informally)?

The only decent argument I've seen against a GC annex is that it
would have to either select a single approach and denigrate all
others, or else provide such a generalized interface as to be a
pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
I know too little about garbage collection research.  The best
refutation would be a strawman of the package(s) and/or the
rules that the annex would provide.

I suspect it mostly didn't get an annex because the pro-GC forces
were sociologically unable to force the issue.


> I suppose you would really be against GC.
...
> I know Robert
> thinks this is "gratuitous rubbish",

Hi, my name is Samuel Mize.  I work for Hughes Training, Inc.  I
have a Masters in Computer Science from Kansas State University
(which included sofware engineering, practical development
methods, and both useful and esoteric theory -- but that's
another thread entirely).

Robert Dewar and I often agree, sometimes disagree, and are
certainly not the same person.

If I unintentionally hit buttons on you that are sensitive
from discussions with him, I apologize.


> > >Does
> > > this mean that explicit freeing of objects via an instance of
> > > Unchecked_Deallocation is discouraged (due to the potential >>>creation of
> > > dangling references)?
> >
> > No.  It just means you should know what you're doing in two areas:
> 
> Well, I disagree.  I think it _does_ have an _intentional_ negative
> connotation for the very reason (and some others) that Kaz points out.

Well, connotations always depend, to some extent, on the reader.
Certainly some of the people involved in the language design process
(83 and 95) would agree with you.

To me, the connotation is "be careful."  It's the difference
between a fellow professional warning you to be careful, and a
mother screaming at a four-year-old to be careful.  (Some of the
language committee are real mothers. :-)


> /Jon

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In another message the same poster writes:

> I'm working on a set of GC subsystems providing a range of generic GC
> variants which will allow you to create various collectors (various
> versions of mark-sweep, mark-compact, copying, generational,
> concurrent, treadmill, etc.) for your supplied type(s).
> ...
> I can't say for sure when all this will be ready, but probably some
> time this summer.

I very much look forward to seeing it.  Is this going to be freely
available (perhaps copyleft), shareware, a product, or what?

Sam Mize

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005