* Re: Ada memory management?
@ 2004-10-07 11:31 Christoph Karl Walter Grein
0 siblings, 0 replies; 15+ messages in thread
From: Christoph Karl Walter Grein @ 2004-10-07 11:31 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
@ 2004-10-07 11:15 Christoph Karl Walter Grein
2004-10-07 12:01 ` Stephen Thomas
0 siblings, 1 reply; 15+ messages in thread
From: Christoph Karl Walter Grein @ 2004-10-07 11:15 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 11:15 Christoph Karl Walter Grein
@ 2004-10-07 12:01 ` Stephen Thomas
0 siblings, 0 replies; 15+ messages in thread
From: Stephen Thomas @ 2004-10-07 12:01 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
@ 2004-10-07 10:00 Christoph Karl Walter Grein
2004-10-07 10:41 ` Stephen Thomas
2004-10-07 12:00 ` Martin Krischik
0 siblings, 2 replies; 15+ messages in thread
From: Christoph Karl Walter Grein @ 2004-10-07 10:00 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 10:00 Christoph Karl Walter Grein
@ 2004-10-07 10:41 ` Stephen Thomas
2004-10-07 11:17 ` Jeff C r e e.m
2004-10-07 14:22 ` Georg Bauhaus
2004-10-07 12:00 ` Martin Krischik
1 sibling, 2 replies; 15+ messages in thread
From: Stephen Thomas @ 2004-10-07 10:41 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 10:41 ` Stephen Thomas
@ 2004-10-07 11:17 ` Jeff C r e e.m
2004-10-07 14:22 ` Georg Bauhaus
1 sibling, 0 replies; 15+ messages in thread
From: Jeff C r e e.m @ 2004-10-07 11:17 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 10:41 ` Stephen Thomas
2004-10-07 11:17 ` Jeff C r e e.m
@ 2004-10-07 14:22 ` Georg Bauhaus
2004-10-07 14:51 ` Stephen Thomas
2004-10-07 16:23 ` Larry Kilgallen
1 sibling, 2 replies; 15+ messages in thread
From: Georg Bauhaus @ 2004-10-07 14:22 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 14:22 ` Georg Bauhaus
@ 2004-10-07 14:51 ` Stephen Thomas
2004-10-07 16:23 ` Larry Kilgallen
1 sibling, 0 replies; 15+ messages in thread
From: Stephen Thomas @ 2004-10-07 14:51 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 14:22 ` Georg Bauhaus
2004-10-07 14:51 ` Stephen Thomas
@ 2004-10-07 16:23 ` Larry Kilgallen
2004-10-07 18:35 ` Frank J. Lhota
1 sibling, 1 reply; 15+ messages in thread
From: Larry Kilgallen @ 2004-10-07 16:23 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 16:23 ` Larry Kilgallen
@ 2004-10-07 18:35 ` Frank J. Lhota
0 siblings, 0 replies; 15+ messages in thread
From: Frank J. Lhota @ 2004-10-07 18:35 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 10:00 Christoph Karl Walter Grein
2004-10-07 10:41 ` Stephen Thomas
@ 2004-10-07 12:00 ` Martin Krischik
1 sibling, 0 replies; 15+ messages in thread
From: Martin Krischik @ 2004-10-07 12:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Ada memory management?
@ 2004-10-07 9:39 matthias_k
2004-10-07 12:06 ` Martin Krischik
2004-10-07 17:24 ` Nick Roberts
0 siblings, 2 replies; 15+ messages in thread
From: matthias_k @ 2004-10-07 9:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 9:39 matthias_k
@ 2004-10-07 12:06 ` Martin Krischik
2004-10-07 17:24 ` Nick Roberts
1 sibling, 0 replies; 15+ messages in thread
From: Martin Krischik @ 2004-10-07 12:06 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 9:39 matthias_k
2004-10-07 12:06 ` Martin Krischik
@ 2004-10-07 17:24 ` Nick Roberts
2004-10-07 19:04 ` Luke A. Guest
1 sibling, 1 reply; 15+ messages in thread
From: Nick Roberts @ 2004-10-07 17:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada memory management?
2004-10-07 17:24 ` Nick Roberts
@ 2004-10-07 19:04 ` Luke A. Guest
0 siblings, 0 replies; 15+ messages in thread
From: Luke A. Guest @ 2004-10-07 19:04 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-10-07 19:04 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-07 11:31 Ada memory management? Christoph Karl Walter Grein
-- strict thread matches above, loose matches on Subject: below --
2004-10-07 11:15 Christoph Karl Walter Grein
2004-10-07 12:01 ` Stephen Thomas
2004-10-07 10:00 Christoph Karl Walter Grein
2004-10-07 10:41 ` Stephen Thomas
2004-10-07 11:17 ` Jeff C r e e.m
2004-10-07 14:22 ` Georg Bauhaus
2004-10-07 14:51 ` Stephen Thomas
2004-10-07 16:23 ` Larry Kilgallen
2004-10-07 18:35 ` Frank J. Lhota
2004-10-07 12:00 ` Martin Krischik
2004-10-07 9:39 matthias_k
2004-10-07 12:06 ` Martin Krischik
2004-10-07 17:24 ` Nick Roberts
2004-10-07 19:04 ` Luke A. Guest
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox