Re: access / freeing memory

[Darren New <dnew@san.rr.com>]

Jan Prazak wrote:
> It says
> something like: "it's better to let the operating system manage it",

That would be called "garbage collection". Some (few, relatively unusual)
OSes implement it, some languages implement it, Ada allows it to be
implemented without requiring it to be implemented, so most Ada programs
don't expect it to be implemented.

On the other hand, if it's a short program that exits, and doesn't use a lot
of memory, it's "safer" to just leave the memory consumed than it is to try
to correctly dispose of it yourself. However, if the program runs for a long
time, you'll eventually run out of memory taking this tact.

> I haven't ever heard of an operating system which can manage memory
> (de)allocations (maybe Linux does it, but I have very little knowledge
> of how Linux works).

Nothing you're likely to have used. Mostly machines targetted at a specific
language, such as Smalltalk machines or Lisp machines will have it built
into the OS.

> I have also read that access types
> in Ada are more secure than pointers in other languages, but I don't see
> any reason, both versions seem to be identical.

Ada has rules that make it difficult for a pointer to point to incorrectly
allocated memory. In C, for example, you could point to a local variable and
return the pointer from the function. Ada disallows this unless you say you
really know what you're doing. Ada also allows you to "intercept"
allocations of memory, so you could do your own garbage collection with
enough effort.
The safety referred to, I think, has little to do with freeing unused
memory, tho.

> and if I do nothing (so the program will end), the operating system (or
> compiler???) does the deallocation automatically,

Yes. 

> just because "head" is
> a variable.

No. The operating system is keeping a similar list, except that instead of
1, 2, 3, it has "John's program", "Mary's compiler", "Fred's spreadsheed".
When Fred's spreadsheet calls the "exit" routine in the operating system,
the OS goes through the linked list to find Fred's spreadsheet and unlinks
the whole chunk of memory. The linked list inside Fred's program is all
inside the one giant chunk of memory that the OS allocated for it, so the OS
doesn't have to look at whether Fred's program thinks it's allocated or not.
It just tosses the whole chunk of memory. (That's a little simplified, but
you get the idea.)

If the OS gets this wrong, eventually memory fills up and the OS crashes,
which is one of the problems that kept Windows NT4 from running web servers
for more than a few months at a time, unlike Linux that lacked this bug and
would run for years.

> >> but it's said that it's not recommended to use it (because some other
> >   Unchecked_Deallocation has that name because it's not checked.  Thus
> > you can really screw up, so it should be used carefully.  Some systems
> > have automatic garbage collection, but most Ada systems don't (problems
> 
> What is an Ada system? You mean systems for which an Ada compiler is
> available?

Most Ada compilers will not generate code that will work right if you assume
there's garbage collection going on. In other words, in Ada, there's enough
information in the source code (and restrictions on how pointers and
addresses can be used) that the compiler *could* generate code that frees up
memory you aren't using. However, most Ada compilers don't generate such
code.
 
> > with real-time timing surprises, for instance).  You can get some
> > automatic deallocation going for you with careful placement of "type ...
> >  is access ..."
> 
> Is this the thing I have explained above?

No.

> > and especially with Storage_Pools.  But mostly, with
> What is a storage pool?

It's when the run-time system code that allocates memory calls a specific
procedure you wrote to find what memory to use. This allows you to write
code to keep track of that yourself, so you can write your own garbage
collector, etc.
 
> > You can
> > usually do stack, rather than heap, allocation which buys automatic,
> > safe, deallocation, and of course speed.
> 
> What do you mean? Why should a FIFO be faster than a LIFO? Or do
> you mean something else by this.

He means usually you can allocate a local variable with a
declare...begin...end (which allocates information on the CPU's stack)
rather than using "new" to allocate something and then specifically have to
free it up. He's basically comparing how you do variable-sized objects in
Ada to how you do variable-sized objects in C (which has no variable-sized
objects, so you have to use "new" (aka malloc) to allocate them) or Java
(which has all objects allocated from the heap, so can't put them on the
stack for efficiency).

You need to learn terms like "heap" and "stack" before a programming
tutorial in Ada is likely to make as much sense as it could. Languages where
the operation of the machine is completely and totally hidden from the user
(APL, BASIC, etc) don't need quite as many technical terms.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

 Proud to live in a country where "fashionable" 
     is denim, "stone-washed" faded, with rips.