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