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?

[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?

[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?

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

ECLAT [was: Ada memory management?]

[Nick Roberts]

Luke A. Guest wrote:

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

Honest truth is, not very far yet. There are a few docs under the 'Docs' link.

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

I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in the 
front and and the back end. I think this is a case where it makes sense to 
'reinvent the wheel'. If people who are new to Ada ask "Are there any free 
compilers?", I think it would sound a lot better to be able to suggest two, 
rather than just one. (I know there is ObjectAda, but it is really only a 
demo version.)

There are some technical reasons why GNAT and GCC are unsuited to what I 
want to achieve.

GNAT's library model is based on source code files directly representing 
the library; this model isn't always ideal. I want to provide a compiler 
that has the more traditional model of a library being stored in a set of 
files which contain all the necessary information (to generate executables) 
in a binary form.

I want ECLAT to be able to target the AdaOS native executable format for 
the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is 
suitable (only) for a 'flat' memory model, and I think adapting it to 
generate code that supports the NEAI/IA-32 segmented architecture would be 
difficult.

-- 
Nick Roberts

Re: ECLAT [was: Ada memory management?]

[Luke A. Guest]

On Thu, 07 Oct 2004 23:52:57 +0100, Nick Roberts wrote:

> Honest truth is, not very far yet. There are a few docs under the 'Docs' link.

I'll have a look, but I have a feeling I may have already read them a
while ago ;-)
 
> I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in
> the front and and the back end. I think this is a case where it makes
> sense to 'reinvent the wheel'. If people who are new to Ada ask "Are
> there any free compilers?", I think it would sound a lot better to be
> able to suggest two, rather than just one. (I know there is ObjectAda,
> but it is really only a demo version.)

It would be two, two different front-ends to GCC, that makes two not one.
 
> There are some technical reasons why GNAT and GCC are unsuited to what I
> want to achieve.
> 
> GNAT's library model is based on source code files directly representing
> the library; this model isn't always ideal. I want to provide a compiler
> that has the more traditional model of a library being stored in a set
> of files which contain all the necessary information (to generate
> executables) in a binary form.

I'm not too sure what you mean here. The old/original way of handling
libraries in Ada (AFAIK) uses a kind of repository where packages are
added when they are compiled, and they have to be removed by hand. GNAT
changes the standard Ada way of handling libraries, by using normal link
libraries and a standard linker.

The only source I see is in the adainclude dir where we have *.ali and
*.ads files.

> I want ECLAT to be able to target the AdaOS native executable format for
> the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is
> suitable (only) for a 'flat' memory model, and I think adapting it to
> generate code that supports the NEAI/IA-32 segmented architecture would
> be difficult.

No offence, but your OS is not going to be too portable in the near
future. Segmentation is being done away with in the 64-bit x86 CPU's
AFAIR. Some CPU's don't support it at all (PPC).

Either way, it would be possible to provide a flat-memory model ECLAT
under GCC, via a front-end port.

Luke.

Re: ECLAT [was: Ada memory management?]

[Nick Roberts]

Luke A. Guest wrote:

>>I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in
>>the front and and the back end. I think this is a case where it makes
>>sense to 'reinvent the wheel'. If people who are new to Ada ask "Are
>>there any free compilers?", I think it would sound a lot better to be
>>able to suggest two, rather than just one. (I know there is ObjectAda,
>>but it is really only a demo version.)
> 
> It would be two, two different front-ends to GCC, that makes two not one.

Okay, but I particularly want to be able to offer a different back end, 
especially one that is written (substantially) in Ada.

>>GNAT's library model is based on source code files directly representing
>>the library; this model isn't always ideal. I want to provide a compiler
>>that has the more traditional model of a library being stored in a set
>>of files which contain all the necessary information (to generate
>>executables) in a binary form.
> 
> I'm not too sure what you mean here. The old/original way of handling
> libraries in Ada (AFAIK) uses a kind of repository where packages are
> added when they are compiled, and they have to be removed by hand. GNAT
> changes the standard Ada way of handling libraries, by using normal link
> libraries and a standard linker.

I think I put this badly. What I mean is that gnatmake refers to source 
code files (specs) when working out which files to recompile (and in what 
order). This requires a certain amount of extra parsing that I want to 
avoid. I also want to totally disconnect source files from the library 
rebuilding process, apart from those source files which are being 
explicitly submitted, so as not to impose avoidable limitations on the way 
source text files are stored (compressed, encrypted, on a different 
machine, privileged, etc.).

>>I want ECLAT to be able to target the AdaOS native executable format for
>>the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is
>>suitable (only) for a 'flat' memory model, and I think adapting it to
>>generate code that supports the NEAI/IA-32 segmented architecture would
>>be difficult.
> 
> No offence, but your OS is not going to be too portable in the near
> future.

AdaOS has been carefully designed so that all code will be 100% portable 
(at the source code level), barring hardware differences (and segmentation 
is surely a hardware difference).

Support for segmentation will be totally implicit in normal Ada code 
(general access values will be segmented, pool-specific ones will not), so 
that porting normal code to another hardware platform will only require 
recompilation. If the hardware does not support segmentation, the compiler 
will emit code which uses the flat memory model.

Only a small amount of the overall AdaOS source code will be 
hardware-dependent.

 > Segmentation is being done away with in the 64-bit x86 CPU's
> AFAIR. Some CPU's don't support it at all (PPC).

In fact both the 32-bit and 64-bit PowerPC architectures are segmented, and 
I intend to make full use of this. The way segmentation works on this 
architecture is different to the 'traditional' model used by the IA-32. All 
segments have the same size, each has a fixed location in the linear 
address space, and they are contiguous. This has the advantage that the 
addressing model can be linear or segmented.

> Either way, it would be possible to provide a flat-memory model ECLAT
> under GCC, via a front-end port.

There are distinct advantages to using a segmented model. It allows you to 
move blocks of data around in your linear address space, and resize them, 
without changing the machine code address of any of the data. This provides 
many benefits: dynamic stack and heap creation and resizing; easy and 
efficient shared module management; it helps with my IPC model.

All these techniques are made necessary by the fact that the 32-bit linear 
space is becoming too small nowadays. The much bigger address space offered 
by 64-bit addressing solves the same problems in a different way.

-- 
Nick Roberts

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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