Q: Ada.Unchecked_Deallocation

Q: Ada.Unchecked_Deallocation

[David Morton]

Quick one here...

If something is created dynamically with new, is it
necessary to deallocate it with Ada.Unchecked_Deallocation,
or will it be removed from the heap space when the program
exits? From the "C" world, I've always been taught to clean
up after myself... is this necessary?  It seems that usually,
"Unchecked" anything in Ada is bad...

Ada95, GNAT on Linux 2.0

Thanks!

-- 
David Morton
 mailto:dmorton@jinx.sckans.edu   http://www.sckans.edu/~dmorton/
 205 College, Winfield, KS 67156    
 This signature will self-destruct in 10 seconds...

Re: Q: Ada.Unchecked_Deallocation

[Jon S Anthony]

In article <31E5D4D1.11DB36E1@jinx.sckans.edu> David Morton <dmorton@jinx.sckans.edu> writes:

> If something is created dynamically with new, is it
> necessary to deallocate it with Ada.Unchecked_Deallocation,

Depends on several things.

> or will it be removed from the heap space when the program
> exits?

This certainly will happen without any help from you.  In fact the heap
itself goes away...


> From the "C" world, I've always been taught to clean up after
> myself... is this necessary?  It seems that usually, "Unchecked"
> anything in Ada is bad...

If you have a garbage collector (like the Intermetrics AppletMagic
Ada/Java system) then you need do nothing in this respect.  If you are
using controlled types for this sort of storage management you will
need to do nothing (well, not after building the types anyway).  If
your program does not allocate "much" as it runs and has a "short"
lifetime, you will not need to bother yourself.  If you have your own
automatic storage management using your own pools with automatic
collections, you will not have to bother (of course, that's a pretty
big "if" as you will have to build it or find one).  Other than that
(and probably a few more) you will need to use Unchecked_Deallocation.

NOTE: "Unchecked" stuff in Ada basically _is_ C stuff!  F'r'stance:
Unchecked_Deallocation is basically just good ol' free (at least from
the user's POV).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Q: Ada.Unchecked_Deallocation

[Robert Dewar]

David Morton says

"If something is created dynamically with new, is it
necessary to deallocate it with Ada.Unchecked_Deallocation,
or will it be removed from the heap space when the program
exits? From the "C" world, I've always been taught to clean
up after myself... is this necessary?  It seems that usually,
"Unchecked" anything in Ada is bad...
"

The entire heap goes away when a program exits anyway in any 
implementation that you are likely to run into (this is why in C++
destructors are not applied to globally allocated objects on the heap,
it is assumed that destructors are usualy used for storage allocation
and so there is no point in calling them at the outer level (*)

Unchecked_Deallocation is not *bad*, if it was bad it would not be in 
the language. It merely is unchecked, that's all. This means that the
checking that is needed is not automatic, and so you have to program
it, not such a terrible thing. In other words, when you use UD, you
promise to behave yourself (i.e. not to free things that were not
allocated, not to free things more than once, and not to reference things
after they are freed), and if you don't behave yourself, your program 
may malfunciton, possibly seriously.

Yes, we prefer to stay away from unchecked stuff where possible, but
if you need it, then it is not bad, it is good!

If you need to clean up storage BEFORE the end of your program, then
you must use UD and be careful (the finalization semantics of Ada 95,
which are analogous to the destructors of Ada 95) are an excellent way
of helping yourself to be careful.

However, cleaning up at the end of the program is unnecessary (I can't believe
any C program would actually go to the trouble of freeing globally allocated
memory before exiting -- are you really saying you do this???)

(*) In Ada, finalization routines *are* called for globally allocated objects
on final program termination, and you can imagine cases (releasing operating
systems locks) where this semantics is critical. However, in Ada 95, as in
C++, 99% of the time finalization is used only for freeing storage, and not
only is it a waste of time to call the finalization routines at the outer
level, but much worse, you waste time and space on the initial allocation
of such objects setting up the data structures to ensure that you can do
these useless finalize calls.

In a garbage collected environment, it is sily to do finalization calls at
any level if all they do is to free storage (and indeed a perfectly
reasonable implementation of Unchecked_Deallocatoin in a garbage collected
environment is to completely ignore all calls to it). So the situation is
even worse.

We talked at one point with Tuck about a pragma that would be applied to 
a type something like

 Finalization_Is_Used_Only_For_Freeing_Storage (type);

(well we need a better name :-)

the effect would be to simply ignore finalize calls at the outer level, or,
in the case of a GC Ada 95, to ignore all finalize calls for the type.

Thoughs?

Re: Q: Ada.Unchecked_Deallocation

[Ron Thompson]

David Morton <dmorton@jinx.sckans.edu> wrote:
>Quick one here...
>
>If something is created dynamically with new, is it
>necessary to deallocate it with Ada.Unchecked_Deallocation,
>or will it be removed from the heap space when the program
>exits? From the "C" world, I've always been taught to clean
>up after myself... is this necessary?  It seems that usually,
>"Unchecked" anything in Ada is bad...
>
>Ada95, GNAT on Linux 2.0
>
>Thanks!
>

The scope of any dynamically allocated object is the same as
the scope of the largest enclosure.
What a mouthful. If the "new" object has a local scope, that 
is it is declared down here in this particular routine, then
it is freed back to OS when this routine closes.
Larger scope, say top of the package body, it would behoove 
the programmer to know whether or not they'll be needin this
thing, and deallocate it when they don't.
Spec or driver scope will live as long as the enclosure as
well, so they should be alloc'd and dealloc'd as needed if
memory is a concern.
Unchecked deallocation has a much scarier name then free().
But free() really is just unchecked deallocation.
The kernel doesn't care WHAT you deallocate, hence unchecked.

rct

The opinions above are mine and mine alone.
Except the scope thing. Thats LRM stuff.

Re: Q: Ada.Unchecked_Deallocation

[Robert Dewar]

Ron Tompson said

"What a mouthful. If the "new" object has a local scope, that
is it is declared down here in this particular routine, then
it is freed back to OS when this routine closes."

First, let's be absolutely clear on what Ron means here, the scope
of a new object is the scope of the corresponding access type (NOT
the scope where the new object is allocated), so the routine being
mentioned in the above is the routine containing the declaration of
the corresponding access type.

Second, this is *allowed* but not *required* behavior by compilers.
Some wording in the Ada 83 RM strongly implied that an implementation
might perform such a free (see description of pragma Controlled in the
Ada 83 RM), but this was still not required (since it is from a formal
point of view undetectable whether the obvject is or is not freed since
it can no longer be referenced anyway). However this language has been
removed from the Ada 95 RM.

Our current view in GNAT is *not* to automatically free such storage
by default (allowing for this automatic free adds quite a bit of
overhead, which may not be needed in many cases). We plan to provide a storage 
pool option that will allow this automatic freeing if it is what you want.
Gven that Ada 95 provides the control of storage pools, this seems the
most reasonable approach.

Consequently Ron's advoice that you don't need to free objects of a local
allocator type if you don't need to free them before scope exit is 
generally incorrect for Ada 95 implementations (I believe the Intermetrics
front end takes the same approach as GNAT).

Re: Q: Ada.Unchecked_Deallocation

[Robert Dewar]

Andy said

"The DEC VMS implementation of Unchecked Allocation and Deallocation is
not totally unchecked.  It is a generic function that will fail at
compile time if the size of the memory to be created/removed is not
the same as the instantiated function.  I assumed other
implementations would do the same.  Are there totally unchecked
implementations out there?"

That's a bit confused, and cannot be right as written since often
UD is used to free items whose size is only known at execution time.
What exactly do you mean here? (or can someone else who knows the
details on this check eludicated). Since Free is a type checked
function like any other in Ada, what could be violated here? One
can imagine a check at the malloc/free type level, but I don't
see that any high level Ada check makes any sense at all.

Re: Q: Ada.Unchecked_Deallocation

[Andy Askey]

David Morton <dmorton@jinx.sckans.edu> wrote:

>If something is created dynamically with new, is it
>necessary to deallocate it with Ada.Unchecked_Deallocation,
>or will it be removed from the heap space when the program
>exits? From the "C" world, I've always been taught to clean
>up after myself... is this necessary?  It seems that usually,
>"Unchecked" anything in Ada is bad...
>Ada95, GNAT on Linux 2.0

>Thanks!
>-- 
>David Morton

The DEC VMS implementation of Unchecked Allocation and Deallocation is
not totally unchecked.  It is a generic function that will fail at
compile time if the size of the memory to be created/removed is not
the same as the instantiated function.  I assumed other
implementations would do the same.  Are there totally unchecked
implementations out there?


--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Q: Ada.Unchecked_Deallocation

[Robert I. Eachus]

In article <dewar.837178582@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

  > We talked at one point with Tuck about a pragma that would be applied to 
  > a type something like

  > Finalization_Is_Used_Only_For_Freeing_Storage (type);

  > (well we need a better name :-)

  > the effect would be to simply ignore finalize calls at the outer level, or,
  > in the case of a GC Ada 95, to ignore all finalize calls for the type.

  > Thoughts?

   Yep.  The lack of a good name means that you are trying to
implement the wrong pragma.  Add a pragma Free or a pragma Collect
to GNAT, where the semantics are to apply respectively
Unchecked_Deallocation or checked deallocation to all the access
values in the record during finalization.

   (You might even want a third pragma that is never called by
assignment, but that is a detail, since Collect should be functionally
identical.)

   Of course an explicit overriding of Finalize for a derived type
should supercede the pragma for that type and its children.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Q: Ada.Unchecked_Deallocation

[Laurent Guerby]

Robert> One: suppose we declare a type KLUNK that has a complex
Robert> finalize routine that frees a KLUNK and all its descendences.

Robert> Now if I have a type

Robert>    type AKLUNK is access KLUNK

Robert> then when I allocate objects of type KLUNK using this access
Robert> type, they will be freed using by complex finalize routine
Robert> when I leave the program, and it is this global finalization
Robert> that I wish to avoid, but of course I still need a
Robert> finalization routine for cases where objects of type KLUNK are
Robert> allocated locally.

   What about (in Ada 95 without extension):

   type KLUNK_WITH_EMPTY_FINALIZE is new KLUNK with null record;
   procedure Finalize (Obj : KLUNK) is
   begin null; end Finalize;

   And instead of applying the pragma, you declare objects of this new type.
A smart compiler can optimize away calls to such a Finalize subprogram.
 
-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Q: Ada.Unchecked_Deallocation

[Robert Dewar]

Laurent said:

   What about (in Ada 95 without extension):

   type KLUNK_WITH_EMPTY_FINALIZE is new KLUNK with null record;
   procedure Finalize (Obj : KLUNK) is
   begin null; end Finalize;

   And instead of applying the pragma, you declare objects of this new type.
A smart compiler can optimize away calls to such a Finalize subprogram.


Robert replies

It would have to be VERY SMART! The body of Finalize appears in the
package body and the client typically only sees the package spec.
And also, this may require introducing conversions all over your program
which you would prefer to avoid.

Re: Q: Ada.Unchecked_Deallocation

[Laurent Guerby]

Robert> It would have to be VERY SMART! The body of Finalize appears
Robert> in the package body and the client typically only sees the
Robert> package spec.  

   A "pragma Inline(Finalize);" can turn your Ada compiler in a VERY
SMART one ;-). Once the compiler has seen the body, it can switch on
the flag that would otherwise be set by the pragma.

Robert> And also, this may require introducing
Robert> conversions all over your program which you would prefer to
                    ^^^^^^^^
Robert> avoid.

   It depends on your application, the conversions are needed when you
assign local KLUNK objects to global KLUNK_Bis ones and
vice-versa. All procedure calls are the same.

   If you find that your application spend too much time in useless
finalization free calls, you turn all objects that don't need it to
KLUNK_Bis, and you add conversions where your compiler tell you so
(helpful strict type checking). Since this optimization is only
helpful when your program is to be launched a great number of time,
and that finalization time is not zero regarding to execution time, I
guess an application needing this optimization won't be that large.

   An alternative design is to set a flag in the run-time saying "now,
don't bother to call free", and to modify Ada.Unchecked_Deallocation
to perform a free call only if this flag is not set (talking about
GNAT implementation here, there's already a check against null). Of
course this doesn't remove all the calls to Finalize, but if free
calls are expensive on your system, that's enough.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Q: Ada.Unchecked_Deallocation

[Robert A Duff]

>In article <dewar.837178582@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>  > Thoughts?

It would really be nice if it were possible to write reusable packages
that work properly with or without GC.  Not easy, since the mere
presence of GC can affect the design (e.g. which operations get exported
from a given package).

- Bob

Re: Q: Ada.Unchecked_Deallocation

[Robert A Duff]

In article <ws9zq4un5ni.fsf@schonberg.cs.nyu.edu>,
Laurent Guerby <guerby@gnat.com> wrote:
>   type KLUNK_WITH_EMPTY_FINALIZE is new KLUNK with null record;
>   procedure Finalize (Obj : KLUNK) is
>   begin null; end Finalize;
>
>   And instead of applying the pragma, you declare objects of this new type.
>A smart compiler can optimize away calls to such a Finalize subprogram.

This would have to be a link-time optimization.

Instead, do it the other way around: Define the no-finalize version
first, and then derive the finalized version from that.  Then, the
compiler *can* tell (at compile time) that the first type has null
Finalize, since it doesn't override the known-null version inherited
from type Controlled.

Either way, you have to be careful, though.  You can't declare nested
objects of the no-finalize type, or you'll get a storage leak.  And what
if it's in a generic package, which is *sometimes* instantiated in a
nested place?

- Bob

Re: Q: Ada.Unchecked_Deallocation

[Robert A Duff]

In article <dewar.837270488@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Our current view in GNAT is *not* to automatically free such storage
>by default (allowing for this automatic free adds quite a bit of
>overhead, which may not be needed in many cases). We plan to provide a storage 
>pool option that will allow this automatic freeing if it is what you want.
>Gven that Ada 95 provides the control of storage pools, this seems the
>most reasonable approach.

Why does GNAT have to provide anything beyond what the language
provides?  It seems to me that you can easily use user-defined storage
pools to make this kind of self-cleaning heap.  Are you just saying that
GNAT will provide such a thing in a library package?  It doesn't seem
like any extra pragmas or options are needed.

- Bob

Re: Q: Ada.Unchecked_Deallocation

[Robert A Duff]

In article <dewar.837178582@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>We talked at one point with Tuck about a pragma that would be applied to 
>a type something like
>
> Finalization_Is_Used_Only_For_Freeing_Storage (type);
>
>(well we need a better name :-)
>
>the effect would be to simply ignore finalize calls at the outer level, ...

I believe an earlier version of Ada 9X proposed that.  Or maybe an
earlier version of the AARM suggested we *might* propose it.  If you
feel like digging through old versions, you might run across a better
name than the above.  ;-)

It does sound like a useful feature.

Note that you might want to do this for non-memory resources, too.  E.g.
you might know that your operating system will close any remaining open
files.

>... or,
>in the case of a GC Ada 95, to ignore all finalize calls for the type.

That part was never proposed, as far as I can remember.

Finalization in the presence of GC is a bit tricky.  It's not obvious
how one should define the *order* in which various finalizations take
place.  Also, it's hard to implement if the Finalize routine is allowed
to resurrect garbage -- that is, the GC determines that some object is
garbage, runs its Finalize, and the Finalize plants a pointer to the
object (or something accessible from the object) somewhere global.

- Bob

Re: Q: Ada.Unchecked_Deallocation

[Uri Shina]

Robert Dewar wrote:
> 
> Andy said
> 
> "The DEC VMS implementation of Unchecked Allocation and Deallocation is
> not totally unchecked.  It is a generic function that will fail at
> compile time if the size of the memory to be created/removed is not
> the same as the instantiated function.  I assumed other
> implementations would do the same.  Are there totally unchecked
> implementations out there?"

I have noticed that memory allocated during a VMS AST wasn't deallocated
by Unchecked Deallocation.

> That's a bit confused, and cannot be right as written since often
> UD is used to free items whose size is only known at execution time.
> What exactly do you mean here? (or can someone else who knows the
> details on this check eludicated). Since Free is a type checked
> function like any other in Ada, what could be violated here? One
> can imagine a check at the malloc/free type level, but I don't
> see that any high level Ada check makes any sense at all.

That's confused and more, it makes servers to exhaust it quata.

Re: Q: Ada.Unchecked_Deallocation

[Theodore E. Dennison]

Uri Shina wrote:
> 
> I have noticed that memory allocated during a VMS AST wasn't deallocated
> by Unchecked Deallocation.

Normal AST, or AST_Entry? Normal AST's need to execute quickly. So 
considering what's involved in storage reclamation, it may be a GOOD thing 
that this happens.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |