Does memory leak?
Duncan Sands
how does it manage not to (without having to use unchecked
deallocation)?
For example, if I have a pointer to a block of memory, and I set
that pointer to null, in simple cases I am ready to believe that
the compiler knows I'm finished with the block... but if the
pointer is to a complicated self-referential structure, some sort
of black magic seems needed to work out whether I'm really
finished with that structure or not. Can this truly be done
efficiently?
You can see that I know nothing about how garbage collection works,
and precious little about what Ada requires for memory management.
I suspect I'm not the only one. If someone could demystify all this
for me, I would be very grateful...
Thanks a lot,
Duncan Sands.
Fred J. McCall
>Does Ada leak memory? I would like to believe it doesn't, but
>how does it manage not to (without having to use unchecked
>deallocation)?
Unless you use unchecked deallocation, there is no guarantee that Ada will
clean up your memory. It is *allowed* to, but isn't required to (from my
reading of the Ada83 Standard, anyway). I had *thought* that even
Unchecked_Deallocation wouldn't guarantee that it was released, but it looks
like it does. The Standard is worded somewhat ambiguously in this case, since
it says that the result of doing an Unchecked_Deallocation is an *indication*
that the storage should be reclaimed, but does not seem to guarantee that the
Ada runtime system will do anything about that indication.
[Hence, if we assume that Unchecked_Deallocation really does mean that the
memory is recovered (rather than merely indicating that it should be), it is
*designers* who leak memory, not Ada. What day is it, again?]
Robert I. Eachus
> Does Ada leak memory? I would like to believe it doesn't, but
> how does it manage not to (without having to use unchecked
> deallocation)?
Ada does not leak memory. Ada is a language standard, and both
Ada 83 and Ada 95 do a good job of always permitting a compiler to do
it right, and of noting where it may be difficult.
Let me take this a little further (and add another candidate for
the top 10 Ada 83 references list ;-) 13.10.1(5) says that "FREE(X),
when X is not equal to null, is an indication that the object
designated by X is no longer required, and that the storage it
occupies is to be reclaimed."
Why the "mealy mouthed" wording? Because it is possible that the
object designated by X is, in fact, still required, and reclaiming the
storage is likely to cause a system crash. No one wanted the RM to
require the run-time to reclaim storage which might be locked by other
processes, etc. AI-356 deals with these sorts of cases, and details
the possible behaviors.
Now, back to the original issue, there are compilers that leak
storage. Some of them are Ada compilers. Much, much more common is
for programmers to write programs that leak storage and blame the
compilers. This is an especially prevelent practice in C. It is much
less common in Ada--in fact in Ada, when it comes to memory leaks,
compiler bugs are a close second to program logic bugs.
There are a very few cases where programs are deliberately
designed to leak storage because it is too expensive to avoid it, but
these are very rare. (One case that I had something to do with
involves a command line parameter package...it may be possible to
determine when the storage required goes away, but in most cases you
would be saving less in stack or heap space than you lose to added
code space.)
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
T. Owen O'Malley
>Does Ada leak memory? I would like to believe it doesn't, but
>how does it manage not to (without having to use unchecked
>deallocation)?
Most (all of the ones that _I've_ seen) of the Ada compilers will lose
track of the memory if you don't call unchecked deallocation. This was
a bad enough problem for us that I wrote a tool named plumber to help
find such leaks. For each block that is lost, it will log the call
stack from where the block was created. Reading the the stack frames,
involves some sparc-specific (SunOS) code. It works with any
combination of C and SunAda code. Plumber is also tasking safe.
For more info:
http://www.ics.uci.edu/~omalley/plumber.html
ftp://liege.ics.uci.edu/pub/arcadia/plumber_1.5.tar.gz
Hope it helps,
Owen
Department of ICS | oma...@ics.uci.edu (ARPA)
UC Irvine | http://www.ics.uci.edu/~omalley/ (WWW)
Irvine, CA 92717 | ucbvax!ucivax!omalley (UUCP)
Robert I. Eachus
> There are several areas where compilers in the early days of Ada leaked.
> One is for a function that returns an unconstrained type. You can't
> allocate stack space for the returned value on the call side because you
> don't know how much space is needed. It's possible though tricky for
> the callee to put the returned value on its own stack space and for the
> caller to reclaim that space later. Early implementations often put the
> result on the heap, and then some failed to release that space. Later,
> pressures of the market place forced such unpleasantness to be fixed.
Yes, very true. In the "early days" of Ada--and I certainly won't
mention names, since current compilers bear no relation--there were
"partial" Ada compilers, quickly brought to market, that had storage
leaks all over the place. I never had this experience with a
validated compiler, although I know there were some leaks in some
versions of validated compilers. But these were usually bugs, not
deliberate design omissions.
> I suspect that the command line package Robert refers to returns type
> STRING, an unconstrained type.
No, the problem was that it retrieved a structure from the OS
containing the (parsed) parameters. There was no easy way to tell
when the user finished making calls to the package without adding a
"finished with engines" call, so the structure was never released. At
the time losing one to two thousand bytes of heap (or stack) was
noticable, but not really serious.
> Note that several functions defined by the standard return unconstrained
> types:
> Text_IO.Name
> Text_IO.Form
> Beginners have a hard time figuring out how to call these.
No, calling is easy--it's what to do with the result that is
hard. ;-) Somehow it seems very counterintuitive that you must
declare an object as a constant only if you can't know the actual
size. Fortunately this problem is gone in Ada 95. One of the many
fixes to "little nits" that make Ada 95 so much nicer to use.
Arthur Evans Jr
eac...@spectre.mitre.org (Robert I. Eachus) wrote:
> There are a very few cases where programs are deliberately
> designed to leak storage because it is too expensive to avoid it, but
> these are very rare. (One case that I had something to do with
> involves a command line parameter package...it may be possible to
> determine when the storage required goes away, but in most cases you
> would be saving less in stack or heap space than you lose to added
> code space.)
There are several areas where compilers in the early days of Ada leaked.
One is for a function that returns an unconstrained type. You can't
allocate stack space for the returned value on the call side because you
don't know how much space is needed. It's possible though tricky for
the callee to put the returned value on its own stack space and for the
caller to reclaim that space later. Early implementations often put the
result on the heap, and then some failed to release that space. Later,
pressures of the market place forced such unpleasantness to be fixed.
I suspect that the command line package Robert refers to returns type
STRING, an unconstrained type.
Note that several functions defined by the standard return unconstrained
types:
Text_IO.Name
Text_IO.Form
Beginners have a hard time figuring out how to call these.
A related problem is string catenation, since "&" returns a string.
Art Evans
Arthur Evans Jr, PhD Phone: 412-963-0839
Ada Consulting FAX: 412-963-0927
461 Fairview Road
Pittsburgh PA 15238-1933
ev...@evans.pgh.pa.us
Henry Baker
Most serious Ada compilers try pretty hard not to leak from internal leaks.
However, objects that you allocate yourself with 'new' are considered your
problem. Huge amounts of network, conference and newsletter bandwidth have been
wasted on trying to get around the fact that Ada doesn't provide a built-in
solution to this problem.
(Of course the situation in Ada is magnified 1000-fold for C++, where detecting
and recovering from memory leaks is a thriving industry.)
[Why is it that people are willing to pay truly large bucks _after_ the fact
for something that they could have gotten relatively cheaply up-front?]
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
Tucker Taft
: Does Ada leak memory?
No, but some implementations do ;-).
: ...I would like to believe it doesn't, but
: how does it manage not to (without having to use unchecked
: deallocation)?
Implementations of Ada are allowed to support automatic storage
reclamation (garbage collection) of storage allocated using
"allocators" (such as "new T") but few if any do so at this point.
Implementations of Ada are expected to automatically reclaim storage
for local variables, even variables whose size is not known
at compile-time. This is often accomplished by using a special
mark/release heap (aka "secondary stack") for such local variables.
Note that Ada is more like C++ than Eiffel/Smalltalk in its
overall approach, since objects are by-default stack resident
rather than heap-resident. In Smalltalk, pretty much everything
lives on the heap, and garbage collection is essential.
(In Eiffel you can have "expanded" objects which can be
implemented as stack-resident objects, though the
default remains non-expanded, heap-resident objects.)
In Ada, you can write very large programs that never use allocators
or the heap.
This "heap-free" approach will not work as well in conjunction
with Ada 95's "class-wide" types, but explicit recycling of
those objects that do need to be heap-resident can minimize the
need for automatic garbage collection. This approach is practical
because not everything is on the heap -- only what needs to be is.
In Ada 95, users can implement their own storage "pools" which
could be used to provide some degree of automatic storage reclamation
for heap objects.
In any case, most users of Ada who do use allocators, also use
Unchecked_Deallocation, which is analogous to "free" of malloc/free fame.
("Free" sounds better than Unchecked_Deallocation, but it is really
the same thing.)
Some Ada users use explicit mark/release, which is typically much
faster, presuming it matches your application needs. I would expect more
use of mark/release in Ada 95 now that users can implement
their own storage pools.
The other relevant new features of Ada 95 are user-defined
assignment and finalization, which are analagous to C++ copy constructors
and destructors. These allow the programmer to get control
when copies are made, or when an object goes out of scope.
These can be used to implement automatic reference-counting-based
management of dynamic storage, which can do the job adequately
for certain applications.
: For example, if I have a pointer to a block of memory, and I set
: that pointer to null, in simple cases I am ready to believe that
: the compiler knows I'm finished with the block... but if the
: pointer is to a complicated self-referential structure, some sort
: of black magic seems needed to work out whether I'm really
: finished with that structure or not. Can this truly be done
: efficiently?
Most (all?) current Ada compilers do not provide garbage collection.
Hence setting a pointer to null will not cause any automatic
storage reclamation in such implementations.
Now that general purpose (though some will say potentially "dangerous")
language-independent "conservative" garbage collectors are available,
I would expect more of them will be integrated with Ada implementations.
True "exact" garbage collection can also be implemented in Ada, but
thus far the market demand for it has not matched the expense of
implementation. It may be that the GNU Modula-3 "exact" garbage collection
support could be adapted to work with the GNU NYU Ada 95 compiler (GNAT).
: You can see that I know nothing about how garbage collection works,
: and precious little about what Ada requires for memory management.
: I suspect I'm not the only one. If someone could demystify all this
: for me, I would be very grateful...
I hope the above helps a little.
The topic of storage management, and the various religious and
technical battles associated therewith, can expand to fill whatever
amount of time you have available, so beware...
: Thanks a lot,
: Duncan Sands.
-Tucker Taft s...@inmet.com
Intermetrics, Inc.
Mike Meier
: Does Ada leak memory? I would like to believe it doesn't, but
: how does it manage not to (without having to use unchecked
: deallocation)?
: For example, if I have a pointer to a block of memory, and I set
: that pointer to null, in simple cases I am ready to believe that
: the compiler knows I'm finished with the block... but if the
: pointer is to a complicated self-referential structure, some sort
: of black magic seems needed to work out whether I'm really
: finished with that structure or not. Can this truly be done
: efficiently?
No, Ada doesn't leak memory. But, some Ada programs (especially
those using C-language X-windows code ;-)) leak memory like a sieve.
In current reality, no Ada run-time environments that I'm aware of provide
automated garbage collection (unless you count deallocation of objects that
fall out of scope), including mainly Alsys and Rational/Verdix. There have
been -long- threads on this subject in this newsgroup in the not too distant
past, and the general consensus seemed to be that garbage collection will
probably not exist in the Ada world soon.
So what do you do? You make sure that you deallocate all dynamically
allocated objects as soon as you're done with them. If the object is
a nested structure containing other dynamically allocated objects, you
deallocate the nested structures first.
The simplest way we found to do this was to modify the Booch components
that we use for almost all dynamic data structures to take care of this
automagically. Of course, in Ada 83 this takes some special tweaking to
properly nested data structures containing private or limited private types.
If you want to be able to determine what data structures are leaking, you
must add a few generic parameters to identify the owner (and any limits you
want to place on the data structure for performance purposes). We even
added a dump facility to print out to a file the memory usage of each
data structure within a process on demand. Believe it or not, none of
this adds all that much overhead to the average data structure
manipulation. Sure would be nice to have some of these features in
the Ada 95 Booch Components by the time we use them (1996 or 1997 maybe).
But, I digress greatly. I hope that I gave you a useful reply somewhere
in there.
Larry Kilgallen, LJK Software
> Most serious Ada compilers try pretty hard not to leak from internal leaks.
> However, objects that you allocate yourself with 'new' are considered your
> problem. Huge amounts of network, conference and newsletter bandwidth have been
> wasted on trying to get around the fact that Ada doesn't provide a built-in
> solution to this problem.
From the Ada83 manual "An implementation may (but need not) reclaim the
storage occupied by an object created by an allocator, once this object
has become inaccessible."
The next section describes the CONTROLLED pragma to forbid implementations
from reclaiming memory except when leaving the innermost "block statement,
subprogram body or task body" enclosing the type declaration.
Is the complaint that Ada should force implementors to reclaim storage,
or that when the CONTROLLED pragma is not used, implementations should
take a less conservative approach than waiting to exit the scope of the
type declaration?
David Weller
>manipulation. Sure would be nice to have some of these features in
>the Ada 95 Booch Components by the time we use them (1996 or 1997 maybe).
Your wish is granted! SOoner than you hoped, too! THanks to some
fine work by Tucker Taft and Pat Rogers, the Ada95 Booch COmponents
should have that feature by early next month (I don't think I'm going
to get that integrated this weekend -- my regression testing isn't
going well right now :-( ).
--
Frustrated with C, C++, Pascal, Fortran? Ada95 _might_ be for you!
For all sorts of interesting Ada95 tidbits, run the command:
"finger dwe...@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
if u cn rd ths, u r gd enuf to chg to Ada :-)
Norman H. Cohen
eac...@spectre.mitre.org (Robert I. Eachus) writes:
|> There are a very few cases where programs are deliberately
|> designed to leak storage because it is too expensive to avoid it, but
|> these are very rare. (One case that I had something to do with
|> involves a command line parameter package...it may be possible to
|> determine when the storage required goes away, but in most cases you
|> would be saving less in stack or heap space than you lose to added
|> code space.)
A few drops of water drip from my shower head after I shut off the water,
but as long as the number of drops is bounded by a constant, I don't call
that a leak.
It sounds as if the case you are talking about involves a bounded amount
of storage allocated ONCE at the beginning of the program. As long as it
does not cause memory to gradually become exhausted as execution
continues, I don't call that a leak either.
The only programs I know of with deliberate memory leaks are those whose
executions are short enough, and whose target machines have enough
virtual memory space, that running out of memory is not a concern.
(This class of programs includes many student programming exercises and
some simple applets and utilities; it includes few if any embedded or
safety-critical programs.)
--
Norman H. Cohen nco...@watson.ibm.com
Robert Dewar
becomes considerably easier, as does keeping track of memory allocation
in general.
kkri...@ionet.net
>Duncan Sands (sa...@clipper.ens.fr) wrote:
>
>In current reality, no Ada run-time environments that I'm aware of provide
>automated garbage collection (unless you count deallocation of objects that
>fall out of scope), including mainly Alsys and Rational/Verdix.
I do know that, under Alsys Ada, you have to worry in about leaking memory.
In a project I worked on, we had a loop similar in format to:
loop
Result := Function_Call_returning_variant_record;
end loop;
We found that there was no reclaimation of memory from the function call
temporary. It went away when we surrounded the call with a begin end block.
It turned out that Alsys only reclaimed memory when a block went out of scope.
After running several hours, megabytes of memory was being eaten up<G>.
-------------------------------------
-- Kevin Krieser
-- kkri...@ionet.net
Fred J. McCall
>No, Ada doesn't leak memory. But, some Ada programs (especially
>those using C-language X-windows code ;-)) leak memory like a sieve.
>In current reality, no Ada run-time environments that I'm aware of provide
>automated garbage collection (unless you count deallocation of objects that
>fall out of scope), including mainly Alsys and Rational/Verdix. There have
>been -long- threads on this subject in this newsgroup in the not too distant
>past, and the general consensus seemed to be that garbage collection will
>probably not exist in the Ada world soon.
>So what do you do? You make sure that you deallocate all dynamically
>allocated objects as soon as you're done with them. If the object is
>a nested structure containing other dynamically allocated objects, you
>deallocate the nested structures first.
Note that this is EXACTLY the approach one should be following in C/C++ (and
any other language that doesn't take care of garbage collection
automagically).
So much for the various bashers.
Henry Baker
Ada83 took a 'see no evil, hear no evil,...' approach to storage management.
Therefore, some of the vendors initially took the same (sloppy) attitude --
e.g., Rational, Telesoft, etc.
It actually takes a great deal of sophistication for a language to offer
automatic, safe, flexible, customizable memory management protocols -- this is
probably why NO language today offers such a collection of features.
From the Ada rationale and the design of Ada, it was clear that automatic
garbage collection was preferred and intended, but never implemented due
to a veto from the intended embedded user community. Unfortunately,
this left Ada in a never-never land where it didn't have _either_ automatic
storage management _or_ not-so-automatic storage management.
This general lack of 'fit and finish' in Ada83 seems more appropriate for
consumer products from the old Soviet Union than one from the U.S.A. Given the
nature of the process which produced Ada83, perhaps there is a lesson here??
Norman H. Cohen
|> From the Ada83 manual "An implementation may (but need not) reclaim the
|> storage occupied by an object created by an allocator, once this object
|> has become inaccessible."
|>
|> The next section describes the CONTROLLED pragma to forbid implementations
|> from reclaiming memory except when leaving the innermost "block statement,
|> subprogram body or task body" enclosing the type declaration.
|>
|> Is the complaint that Ada should force implementors to reclaim storage,
|> or that when the CONTROLLED pragma is not used, implementations should
|> take a less conservative approach than waiting to exit the scope of the
|> type declaration?
The wish is for implementations to take a less conservative approach,
i.e., to provide garbage collection in the absence of the Controlled
pragma. Waiting to exit the scope of a type declaration is a far more
conservative approach than you make it sound, since interesting access
types are typically declared in library packages, and thus do not go out
of scope until the program is done!
Kennel
> [Why is it that people are willing to pay truly large bucks _after_ the fact
> for something that they could have gotten relatively cheaply up-front?]
Oh Don't You See It's A Good Thing That C++ Has Such A Thriving Commercial
Aftermarket Industry.
Theodore Dennison
UNCHECKED_DEALLOCATION?
I mean, if you don't deallocate what you allocate, your program will
leak memory no matter what language it is written in. This isn't an Ada
issue, it's an issue of sloppy coding.
T.E.D.
Duncan Sands
Many thanks to everyone who replied to my question "Does
memory leak": Fred J. McCall (f...@ti.com), Robert I. Eachus
(eac...@spectre.mitre.org), T. Owen O'Malley
(oma...@porte-de-st-ouen.ics.uci.edu), Keith Thompson
(k...@alsys.com), Karl (ka...@grebyn.com), Arthur Evans Jr
(ev...@evans.pgh.pa.us), Henry Baker (hba...@netcom.com),
Larry Kilgallen (kilg...@eisner.decus.org) and everyone
else.
The short answer seems to be: (1) some early compilers were
a bit buggy and leaked, but this is no longer a problem.
(2) if you allocate memory on the free store, you are
responsable for it: some implementations may garbage collect
but not all.
Thanks again,
Duncan Sands.
Theodore Dennison
> In article <EACHUS.95M...@spectre.mitre.org>,
> eac...@spectre.mitre.org (Robert I. Eachus) writes:
>
> It sounds as if the case you are talking about involves a bounded amount
> of storage allocated ONCE at the beginning of the program. As long as it
> does not cause memory to gradually become exhausted as execution
> continues, I don't call that a leak either.
>
.unless your package ends up running on a platform without virtual memory.
Many of the smaller O.S.'s don't have the ability to recover this memory when
a program terminates. If there is any chance your code might be re-used on
such a platform, please do not code this way! At least deallocate this memory
upon program termination (and don't forget those exception handlers).
T.E.D. (structured programming bigot)
John DiCamillo
Huh? Haven't you ever worked with a garbage-collected language?
Languages like Smalltalk allow you to allocate stuff all day,
and they don't even have a deallocate operation; the run-time
system figures out when the program is done with a piece of storage
and deallocates it for you.
>T.E.D.
--
ciao,
milo
================================================================
John DiCamillo Fiery the Angels Fell
mi...@netcom.com Deep thunder rode around their shores
Henry Baker
<denn...@escmail.orl.mmc.com> wrote:
Not necessarily true. I've written lots and lots of Lisp programs, and
I think that I forgot to deallocate in almost all of them. They worked
just fine.
(Of course I'm being facetious. Lisp doesn't have a deallocate primitive,
because it has an automatic garbage collector, just like Modula and Eiffel.
Furthermore, garbage collection can't collect stuff that is still linked
to live objects, so you can still get a 'leak' this way.)
Robb Nebbe
|> Theodore Dennison <denn...@escmail.orl.mmc.com> writes:
|>
|> >I mean, if you don't deallocate what you allocate, your program will
|> >leak memory no matter what language it is written in. This isn't an Ada
|> >issue, it's an issue of sloppy coding.
|>
|> Languages like Smalltalk allow you to allocate stuff all day,
|> and they don't even have a deallocate operation; the run-time
|> system figures out when the program is done with a piece of storage
|> and deallocates it for you.
|>
Garbage collection doesn't change the fact that someone has to
deallocate the memory it just changes who is responsible. In
general it really isn't an issue of sloppy code; however, if
the programmer is responsible then it is an issue of sloppy
code.
Robb Nebbe
Theodore Dennison
> Huh? Haven't you ever worked with a garbage-collected language?
> Languages like Smalltalk allow you to allocate stuff all day,
> and they don't even have a deallocate operation; the run-time
> system figures out when the program is done with a piece of storage
> and deallocates it for you.
>
Unfortunately, I never had a working copy of Smalltalk to learn from.
I have used Lisp, but as I remember, Lisp is different. Lisp doesn't
really have an "allocate" call. Lisp varibles are more like Ada
variables, so it is natural to let the compiler worry about managing
them. The point is, if a language provides "allocate" and "deallocate"
functions, you should "deallocate" what you "allocate".
T.E.D.
Robert I. Eachus
In article <3l6gf6$h...@theopolis.orl.mmc.com>, Theodore Dennison
<denn...@escmail.orl.mmc.com> wrote:
> I mean, if you don't deallocate what you allocate, your program will
> leak memory no matter what language it is written in. This isn't an Ada
> issue, it's an issue of sloppy coding.
> Not necessarily true. I've written lots and lots of Lisp programs, and
> I think that I forgot to deallocate in almost all of them. They worked
> just fine.
> (Of course I'm being facetious. Lisp doesn't have a deallocate primitive,
> because it has an automatic garbage collector, just like Modula and Eiffel.
> Furthermore, garbage collection can't collect stuff that is still linked
> to live objects, so you can still get a 'leak' this way.)
The truth is somewhere in between, but a lot closer to Ted's
position. It is ALWAYS sloppy coding to leave garbage lying around.
In some languages--including LISP and Ada 95--it is possible to get
the compiler/language to do most of the work for you, but it is still
the programmer's responsibility to see that garbage is visible as
such.
In LISP, most garbage is automatically collected, but pathological
misuse of memory can slow performance to a crawl, and leaving pointers
to memory no longer in use lying around can quickly run you out of
memory.
In Ada, most allocation and reclamation is from the user's point
of view automatically controlled by the compiler. With a bit of
attention to scope entries and exits you can manage quite elaborate
structures without ever having to call an instance of
Unchecked_Deallocation. Reorganize the code slightly and all of those
allocators are at the outermost scope level and your program dies a
nasty death.
I find that memory management in both is about the same level of
effort. A little bit of thinking about the real storage model is a
constant necessity, but it is very seldom an issue you spend any time
worring about.
Kent Mitchell
: The only programs I know of with deliberate memory leaks are those whose
: executions are short enough, and whose target machines have enough
: virtual memory space, that running out of memory is not a concern.
: (This class of programs includes many student programming exercises and
: some simple applets and utilities; it includes few if any embedded or
: safety-critical programs.)
This sparked and interesting memory for me. I was once working with a
customer who was producing on-board software for a missile. In my analysis
of the code, I pointed out that they had a number of problems with storage
leaks. Imagine my surprise when the customers chief software engineer said
"Of course it leaks". He went on to point out that they had calculated the
amount of memory the application would leak in the total possible flight time
for the missile and then doubled that number. They added this much
additional memory to the hardware to "support" the leaks. Since the missile
will explode when it hits it's target or at the end of it's flight, the
ultimate in garbage collection is performed without programmer intervention.
--
Kent Mitchell | One possible reason that things aren't
Technical Consultant | going according to plan is .....
Rational Software Corporation | that there never *was* a plan!
John Baker
: In article <3l6gf6$h...@theopolis.orl.mmc.com>, Theodore Dennison
: <denn...@escmail.orl.mmc.com> wrote:
: > Perhaps I'm missing something here...what exactly is wrong with using
: Not necessarily true. I've written lots and lots of Lisp programs, and
: I think that I forgot to deallocate in almost all of them. They worked
: just fine.
: (Of course I'm being facetious. Lisp doesn't have a deallocate primitive,
: because it has an automatic garbage collector, just like Modula and Eiffel.
: Furthermore, garbage collection can't collect stuff that is still linked
: to live objects, so you can still get a 'leak' this way.)
The Lisp i programmed in (symbolics) had a really nice feature --
allocation to *named* areas of memory. You could allocate
objects with differing life spans in different areas and then
(at the appropriate time), wipe a whole named area and start over
without having to destroy the objects individually. Very fast
and easy to control. I'd like to see a feature like that in C++
and ADA.
JB
Sverre Brubaek
|> Henry Baker (hba...@netcom.com) wrote:
|> : In article <3l6gf6$h...@theopolis.orl.mmc.com>, Theodore Dennison
|> : <denn...@escmail.orl.mmc.com> wrote:
|>
|> : I think that I forgot to deallocate in almost all of them. They worked
|> : just fine.
|>
|> : (Of course I'm being facetious. Lisp doesn't have a deallocate primitive,
|> : because it has an automatic garbage collector, just like Modula and Eiffel.
|> : Furthermore, garbage collection can't collect stuff that is still linked
|> : to live objects, so you can still get a 'leak' this way.)
|>
|> The Lisp i programmed in (symbolics) had a really nice feature --
|> allocation to *named* areas of memory. You could allocate
|> objects with differing life spans in different areas and then
|> (at the appropriate time), wipe a whole named area and start over
|> without having to destroy the objects individually. Very fast
|> and easy to control. I'd like to see a feature like that in C++
|> and ADA.
|>
|> JB
I'll just quote from the RM:
13.11 Storage Management
(1)
Each access-to-object type has an associated storage pool. The storage
allocated by an allocator comes from the pool; instances of
Unchecked_Deallocation return storage to the pool. Several access types
can share the same pool.
(2)
A storage pool is a variable of a type in the class rooted at
Root_Storage_Pool, which is an abstract limited controlled type. By
default, the implementation chooses a standard storage pool for each
access type. The user may define new pool types, and may override the
choice of pool for an access type by specifying Storage_Pool for the type.
I'd say this looks pretty much like the feature you wanted.
P.S. Although it has been said before, Ada is _not_ spelled in capitals.
--
+-------------------------------Sverre Brubaek--------------------------------+
| e-mail s4...@brems.ii.uib.no | s-mail Stoeletorget 10, 5003 bergen |
| v-mail (+47) 55 96 24 81 | www http://brems.ii.uib.no/~s424/ |
+-------------------------------------+---------------------------------------+
- --** Team os/2 **-- - - - --** Team Ada **-- - - - --** MNIF-stud **-- -
Tucker Taft
: The Lisp i programmed in (symbolics) had a really nice feature --
: allocation to *named* areas of memory. You could allocate
: objects with differing life spans in different areas and then
: (at the appropriate time), wipe a whole named area and start over
: without having to destroy the objects individually. Very fast
: and easy to control. I'd like to see a feature like that in C++
: and ADA.
This is essentially equivalent to "mark/release." This is supported
in Ada 95 via user-defined storage pools. There is an example in the
Ada 95 Rationale on this (see section on "Storage Pool Management").
Similar things are possible in C++ by overloading the "new" operation.
: JB
Pat Rogers
John Baker <jba...@thor.tu.hac.com> wrote:
>
>The Lisp i programmed in (symbolics) had a really nice feature --
>allocation to *named* areas of memory. You could allocate
>objects with differing life spans in different areas and then
>(at the appropriate time), wipe a whole named area and start over
>without having to destroy the objects individually. Very fast
>and easy to control. I'd like to see a feature like that in C++
>and ADA.
Piece of cake using Pools in Ada95. For that matter, using the Booch
Components (version '95) that should be directly supportable on a per-
component basis.
--
Pat Rogers
pro...@acm.org
Ray Toal
>Henry Baker (hba...@netcom.com) wrote:
>: In article <3l6gf6$h...@theopolis.orl.mmc.com>, Theodore Dennison
>: <denn...@escmail.orl.mmc.com> wrote:
>: > Perhaps I'm missing something here...what exactly is wrong with using
>: Not necessarily true. I've written lots and lots of Lisp programs, and
>: I think that I forgot to deallocate in almost all of them. They worked
>: just fine.
>: (Of course I'm being facetious. Lisp doesn't have a deallocate primitive,
>: because it has an automatic garbage collector, just like Modula and Eiffel.
>: Furthermore, garbage collection can't collect stuff that is still linked
>: to live objects, so you can still get a 'leak' this way.)
>The Lisp i programmed in (symbolics) had a really nice feature --
>allocation to *named* areas of memory. You could allocate
>objects with differing life spans in different areas and then
>(at the appropriate time), wipe a whole named area and start over
>without having to destroy the objects individually. Very fast
>and easy to control. I'd like to see a feature like that in C++
>and ADA.
>JB
Certainly they exist, but you have to write them yourself. In C++
you can overload the 'new' operator to allocate to your own arenas.
Ada suggests that implementations manage the "heap" as a collection
of pools that "belong to" specific access types; since this is only
implementation advice you may have to simulate this yourself if your
compiler supports neither automatic garbage collection or pools.
You can in any modern language define a particular array to use for
allocation of certain objects and write an allocation procedure.
In fact, it is a good idea because a memory pool in which all objects
are of the same size is not subject to fragmentation and allocation/
deallocation is O(1).
Ray Toal
Norman H. Cohen
(Tucker Taft) writes:
|> John Baker (jba...@thor.tu.hac.com) wrote:
|>
|> : The Lisp i programmed in (symbolics) had a really nice feature --
|> : allocation to *named* areas of memory. You could allocate
|> : objects with differing life spans in different areas and then
|> : (at the appropriate time), wipe a whole named area and start over
|> : without having to destroy the objects individually. Very fast
|> : and easy to control. I'd like to see a feature like that in C++
|> : and ADA.
|>
|> This is essentially equivalent to "mark/release."
No, mark/release is for FIFO deallocation. What John has described
allows a compiler writer, for example, to allocate data structures that
will persist over all phases of the compiler (for example aliasing
information computed by the front end and used during optimization) in
one area, and to allocate data structures that are only needed during the
first pass (for example a symbol table for nonexternal symbols) in
another area, INTERLEAVING ALLOCATIONS IN THE TWO AREAS, and then to
destroy the second area in its entirety after the first pass, leaving the
first area intact. Mark/release would not allow the interleaving.
|> This is supported
|> in Ada 95 via user-defined storage pools. There is an example in the
|> Ada 95 Rationale on this (see section on "Storage Pool Management").
Ada 95 does indeed solve the problem, but it is the ability to explicitly
associate different storage pools with different access types (and the
ability to control when a storage-pool object is finalized) that solves
the problem, not the addition of Mark and Release operations.
Allocation in areas (which could themselves be allocated and deallocated)
was a very useful feature of PL/I, and I'm glad to see it is not
forgotten.
Tucker Taft
: (Tucker Taft) writes:
: |> John Baker (jba...@thor.tu.hac.com) wrote:
: |>
: |> : The Lisp i programmed in (symbolics) had a really nice feature --
: |> : allocation to *named* areas of memory. You could allocate
: |> : objects with differing life spans in different areas and then
: |> : (at the appropriate time), wipe a whole named area and start over
: |> : without having to destroy the objects individually. Very fast
: |> : and easy to control. I'd like to see a feature like that in C++
: |> : and ADA.
: |>
: |> This is essentially equivalent to "mark/release."
: No, mark/release is for FIFO deallocation.
Oops, I bet you meant "LIFO".
And I meant "mark/release with multiple heaps" which *is*
essentially equivalent. In fact, M/R with multiple heaps
is a bit more flexible, since you don't have to release
an entire heap, but can instead release just part of a heap.
: ...
: Norman H. Cohen nco...@watson.ibm.com
-Tucker Taft s...@inmet.com
Norman H. Cohen
(Tucker Taft) writes:
|> Norman H. Cohen (nco...@watson.ibm.com) wrote:
|> : In article <D6KtA...@inmet.camb.inmet.com>, s...@spock.camb.inmet.com
|> : (Tucker Taft) writes:
|> : |> This is essentially equivalent to "mark/release."
|>
|> : No, mark/release is for FIFO deallocation.
|>
|> Oops, I bet you meant "LIFO".
Oops!
|>
|> And I meant "mark/release with multiple heaps" which *is*
|> essentially equivalent. In fact, M/R with multiple heaps
|> is a bit more flexible, since you don't have to release
|> an entire heap, but can instead release just part of a heap.
True.