Ada memory management?

Ada memory management?

[matthias_k]

Hey there,

since there is an allocator 'new' in Ada, I was wondering if there is a 
'delete' too. I've heard there is a special technique called Storage 
Pool in Ada to write own memory managers, but what is the default 
deallocator?

Consider this code:

procedure Does_This_Leak is
    type Int_Ptr is access Integer;
    ptr: Int_Ptr;
begin
    ptr := new Integer;
end Does_This_Leak;

Will this procedure leak? Or does Ada somehow deal on its own with the 
allocation.

Thanks in advance,
Matthias

Re: Ada memory management?

[Christoph Karl Walter Grein]

procedure Does_This_Leak is
    type Int_Ptr is access Integer;
    ptr: Int_Ptr;
begin
    ptr := new Integer;
end Does_This_Leak;

Of course this leaks, and imagine how much!

Consider Ada.Unchecked_Deallocation. It's called Unchecked because it's your very chore to take care of not
producing dangling pointers.
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Ada memory management?

[Stephen Thomas]

On Thu, 07 Oct 2004 12:00:42 +0200, Christoph Karl Walter Grein wrote:

> procedure Does_This_Leak is
>     type Int_Ptr is access Integer;
>     ptr: Int_Ptr;
> begin
>     ptr := new Integer;
> end Does_This_Leak;
> 
> Of course this leaks, and imagine how much!

Actually, no it shouldn't, not on a halfway-decent implementation.
Logically speaking, a storage pool for items accessed via values of
an access type has the same lifetime as the access type itself. In
the above example, a new storage pool for Int_Ptr is created on
entry to Does_This_Leak, and is removed on exit.

Stephen
-- 
Your name is being called by sacred things
That are not addressed nor listened to.
Sometimes they blow trumpets.

Re: Ada memory management?

[Christoph Karl Walter Grein]

Stephen Thomas:
> > procedure Does_This_Leak is
> >     type Int_Ptr is access Integer;
> >     ptr: Int_Ptr;
> > begin
> >     ptr := new Integer;
> > end Does_This_Leak;
> > 
> > Of course this leaks, and imagine how much!
> 
> Actually, no it shouldn't, not on a halfway-decent implementation.
> Logically speaking, a storage pool for items accessed via values of
> an access type has the same lifetime as the access type itself. In
> the above example, a new storage pool for Int_Ptr is created on
> entry to Does_This_Leak, and is removed on exit.

RM 13.11(17) If Storage_Pool is not specified ... then the implementation chooses a standard storage pool .. in an implementation-defined manner.

So how do you arrive at this statement?

But see RM 13.11(18): The case is different if a Storage_Size is defined.
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

Re: Ada memory management?

[Jeff C r e e.m]

"Stephen Thomas" <vianews@stephenthomas.uklinux.net> wrote in message 
news:pan.2004.10.07.10.41.56.495730@stephenthomas.uklinux.net...
> On Thu, 07 Oct 2004 12:00:42 +0200, Christoph Karl Walter Grein wrote:
>
>> procedure Does_This_Leak is
>>     type Int_Ptr is access Integer;
>>     ptr: Int_Ptr;
>> begin
>>     ptr := new Integer;
>> end Does_This_Leak;
>>
>> Of course this leaks, and imagine how much!
>
> Actually, no it shouldn't, not on a halfway-decent implementation.
> Logically speaking, a storage pool for items accessed via values of
> an access type has the same lifetime as the access type itself. In
> the above example, a new storage pool for Int_Ptr is created on
> entry to Does_This_Leak, and is removed on exit.
>
> Stephen
> -- 


Stephen is correct...But just to be clear (because this is where people (not 
Stephen) get confused is that the following
(much more common construct) would leak unless unchecked_deallocation is 
used.

package body Like_A_Sieve is

     type Int_Ptr is access Integer;

procedure Does_This_Leak is
     ptr: Int_Ptr;
begin
     ptr := new Integer;
 end Does_This_Leak;

end Like_A_Sieve;

It is a rare (though still useful) construct to be able to get away with 
having the pointer type declaration totally within a short lived procedure.

Sieve 

Re: Ada memory management?

[Christoph Karl Walter Grein]

Jeff C r e e.m:
> > Actually, no it shouldn't, not on a halfway-decent implementation.
> > Logically speaking, a storage pool for items accessed via values of
> > an access type has the same lifetime as the access type itself. In
> > the above example, a new storage pool for Int_Ptr is created on
> > entry to Does_This_Leak, and is removed on exit.
> >
> > Stephen
> > -- 
> 
> 
> Stephen is correct...But just to be clear (because this is where people (not 
> Stephen) get confused is that the following
> (much more common construct) would leak unless unchecked_deallocation is 
> used.

No, he isn't, see my previous post! To get this effect, you have to define Storage_Size or a local storage pool.

> package body Like_A_Sieve is
> 
>      type Int_Ptr is access Integer;
> 
> procedure Does_This_Leak is
>      ptr: Int_Ptr;
> begin
>      ptr := new Integer;
>  end Does_This_Leak;
> 
> end Like_A_Sieve;

But your example is also correct.
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

Re: Ada memory management?

[Martin Krischik]

Christoph Karl Walter Grein wrote:

> procedure Does_This_Leak is
>     type Int_Ptr is access Integer;
>     ptr: Int_Ptr;
> begin
>     ptr := new Integer;
> end Does_This_Leak;
> 
> Of course this leaks, and imagine how much!

Well depends if garbage collection is available. The sad news are that only
Ada's targeting JVM have garbage collection.
 
> Consider Ada.Unchecked_Deallocation. It's called Unchecked because it's
> your very chore to take care of not producing dangling pointers.

Or using a garbage collected storrage pool.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada memory management?

[Stephen Thomas]

On Thu, 07 Oct 2004 13:15:58 +0200, Christoph Karl Walter Grein wrote:

> RM 13.11(17) If Storage_Pool is not specified ... then the implementation chooses a standard storage pool .. in an implementation-defined manner.
> 
> So how do you arrive at this statement?
> 
> But see RM 13.11(18): The case is different if a Storage_Size is defined.

Because if clause RM13.11(17) holds in a particular case, the
implementation may choose to behave as if *it* had selected appropriate
S'Storage_Pool and/or S'Storage_Size, and then behave as per RM13.11(18).
Or it may not choose to do that, it is up to the implementation.

Stephen

-- 
Your name is being called by sacred things
That are not addressed nor listened to.
Sometimes they blow trumpets.

Re: Ada memory management?

[Martin Krischik]

matthias_k wrote:

> Hey there,
> 
> since there is an allocator 'new' in Ada, I was wondering if there is a
> 'delete' too. I've heard there is a special technique called Storage
> Pool in Ada to write own memory managers, but what is the default
> deallocator?

Two option open: Your Ada has garbage collection or you use
Ada.Unchecked_Deallocation.

AFAIK: Only Ada's targeting the JVM have garbage collection. However for
GNAT you can use the Boehm Collector which is part of the GCC.

Mind you: A good collection class library will free you from almost all
memory management.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Ada memory management?

[Georg Bauhaus]

Stephen Thomas <vianews@stephenthomas.uklinux.net> wrote:

:  In
: the above example, a new storage pool for Int_Ptr is created on
: entry to Does_This_Leak, and is removed on exit.

A whole pool is created on procedure entry? Are you sure?


-- georg

Re: Ada memory management?

[Stephen Thomas]

On Thu, 07 Oct 2004 14:22:14 +0000, Georg Bauhaus wrote:
> A whole pool is created on procedure entry? Are you sure?

The implementation is free to create a new pool when a new access type
comes into being, and can destroy that pool when the type goes out
of scope. In the original example, this coincides with procedure entry
and exit.

As it happens, GNAT (as of 3.15p) does not seem to behave this way, and
the original example does indeed leak heavily. The point I'm making,
however, is that you cannot necessarily assume that it will leak in all
Ada implementations. That said, assuming that many Ada implementors would
consider storage pool creation/destruction to be expensive (which I think
may be your concern), then I suspect most implementations would not try
to create pools dynamically in this fashion.

Stephen

-- 
Your name is being called by sacred things
That are not addressed nor listened to.
Sometimes they blow trumpets.

Re: Ada memory management?

[Larry Kilgallen]

In article <ck3jem$72a$1@a1-hrz.uni-duisburg.de>, Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> Stephen Thomas <vianews@stephenthomas.uklinux.net> wrote:
> 
> :  In
> : the above example, a new storage pool for Int_Ptr is created on
> : entry to Does_This_Leak, and is removed on exit.
> 
> A whole pool is created on procedure entry? Are you sure?

"A whole pool" _might_ be cheap (or not).

I don't know the internals of the VMS Ada compiler, but the operating
system function LIB$CREATE_VM_ZONE is a relatively cheap way to make
something that could be used as a pool by an implementation.

Re: Ada memory management?

[Nick Roberts]

matthias_k wrote:

> Hey there,
> 
> since there is an allocator 'new' in Ada, I was wondering if there is a 
> 'delete' too. I've heard there is a special technique called Storage 
> Pool in Ada to write own memory managers, but what is the default 
> deallocator?
> 
> Consider this code:
> 
> procedure Does_This_Leak is
>    type Int_Ptr is access Integer;
>    ptr: Int_Ptr;
> begin
>    ptr := new Integer;
> end Does_This_Leak;
> 
> Will this procedure leak? Or does Ada somehow deal on its own with the 
> allocation.

There are some Ada implementations where memory never leaks (unless a bug 
in the compiler or run time system causes one, or the programmer causes it 
by poor unchecked or external programming). Automatic deallocation combined 
with comprehensive memory reclamation is called 'full garbage collection'. 
I think, in reality, there is no native code Ada compiler which supports 
full garbage collection.

Personally, I regret this situation. The compiler vendors all say they 
don't support full garbage collection because there is no demand, which is 
true considering the paying Ada compiler market is almost entirely made up 
of the embedded, real-time, and safety-critical arenas. But the fact that 
the Ada language is capable of protecting the programmer from the 
possibility of memory leaks used to be, many years ago, one of the reasons 
cited for its superiority. The complete lack of support for full garbage 
collection seems unfortunate to me. It is a proud capability of many 
languages which have since become far more popular than Ada.

I am trying to build my own (open source, GPL) Ada compiler, and I hope to 
be able to build in full garbage collection support, if only to prove that 
it can be done. But I do not have recourse to huge resources, so don't hold 
your breath.

    http://sourceforge.net/projects/eclat

I am a (moderate) fan of full garbage collection, but I concede that it is 
not, in reality, as useful as you might think. One could guess that 90% of 
'desktop' Ada programs would not benefit from the availablity of full 
garbage collection, for one of the following reasons: the program does 
little or no dynamic memory allocation; the program does not give any (or 
much) opportunity for automatic deallocation until (near) the end of 
program execution; more control over the management of (most) dynamically 
allocated variables is required; the program must be written to be portable 
to other Ada compilers (which do not or may not support full garbage 
collection); the program only uses pre-written encapsulated 'containers' 
for dynamic data storage, which all do their own memory management anyway.

Many programs will only dynamically allocate variables of a fixed size 
(known at compile time). By having a separate pool for each different size, 
the necessity for memory reclamation (moving things around) is obviated; 
only automatic deallocation is useful. I do not know if any existing native 
code Ada compiler actually supports this technique (doing it 
automatically). It could be done manually, by implementing one's own 
storage pool.

Probably, full garbage collection would never be used for an embedded or 
real-time program, because it is a big-memory technique, and does not 
conform to strict timing requirements. I'm not quite sure about 
safety-critical programs.

However, for the remaining 10% -- or whatever the figure really is -- of 
desktop programs, full garbage collection would certainly be a useful 
facility, and I am certain it is why many good programmers often choose 
languages such as Python, Ruby, and various others which support it, in 
preference to a language which (in practice) doesn't.

-- 
Nick Roberts

Re: Ada memory management?

[Frank J. Lhota]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:AynU0Y9RbXiP@eisner.encompasserve.org...
>> A whole pool is created on procedure entry? Are you sure?
>
> "A whole pool" _might_ be cheap (or not).
>
> I don't know the internals of the VMS Ada compiler, but the operating
> system function LIB$CREATE_VM_ZONE is a relatively cheap way to make
> something that could be used as a pool by an implementation.

In the Win32 API, HeapCreate() can serve the same purpose, and HeapDestroy() 
can be used to clean up after exiting the procedure.

Re: Ada memory management?

[Luke A. Guest]

On Thu, 07 Oct 2004 18:24:21 +0100, Nick Roberts wrote:

> I am trying to build my own (open source, GPL) Ada compiler, and I hope to 
> be able to build in full garbage collection support, if only to prove that 
> it can be done. But I do not have recourse to huge resources, so don't hold 
> your breath.
> 
>     http://sourceforge.net/projects/eclat

Erm, how far are you with this project Nick? I've known about it for a
while and your page doesn't really have anything on it (yet), how about an
update?

Also, are you using GCC at all? That would be interesting; it might spur
some competition with ACT ;-D If you're not using GCC, maybe you should
try using it to speed up development.

Luke.