* garbage collection @ 1999-08-18 0:00 Ronald Ayoub 1999-08-18 0:00 ` tmoran ` (3 more replies) 0 siblings, 4 replies; 28+ messages in thread From: Ronald Ayoub @ 1999-08-18 0:00 UTC (permalink / raw) In the book "Programming in Ada 95" by Barnes he says: If an allocated object becomes inaccessbile becasue no declard objects refer to it directly or indirectly then the storage it occupies may be reclaimed so that it can be reused for other objects. An implementation may (but need not) provide garbage collection for this. I need this to be clarified for me. If an implementation doesn't provide garbage collection then that storage is forever lost, is that correct? Or does this mean that it may not be garbage collected but when a call to new is executed it is at that time scene as available. Please clarify. This seems like a real bad idea not to have some form of garbage collection inforced. Ron ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 garbage collection Ronald Ayoub @ 1999-08-18 0:00 ` tmoran 1999-08-18 0:00 ` Keith Thompson 1999-08-18 0:00 ` garbage collection Gisle S�lensminde ` (2 subsequent siblings) 3 siblings, 1 reply; 28+ messages in thread From: tmoran @ 1999-08-18 0:00 UTC (permalink / raw) > If an implementation doesn't provide garbage collection then that > storage is forever lost, is that correct? No. When the access type goes out of scope there is clearly no way the storage can be on the target end of a pointer, so the implementation should free that storage. With the 'Storage_Size attribute on the access type, "the storage for the pool is reclaimed when the master containing the declaration of the access type is left". If that's not soon enough, you have several options, including: 1) Ada.Unchecked_Deallocation (the equivalent of "free"), if you are careful not to deallocate and later refer to the same storage. 2) Use a controlled type so your Finalize routine can recycle storage. 3) Do your own storage management for the relevant types using the Storage_Pool facility. See Barnes, section 21.4 for a good discussion of storage management. 4) The most straightforward way, as has been pointed out, is not to use "new" unnecessarily. Since you can declare dynamically sized things inside a subroutine, and can nest subroutines, storage that is allocated in a stack-like (first allocated is last deallocated) style can normally be handled with simple declarations, without the overhead or dangers of "new". With tasks, you can even have several separate stack-like allocations going on at once. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` tmoran @ 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Tucker Taft 1999-08-20 0:00 ` tmoran 0 siblings, 2 replies; 28+ messages in thread From: Keith Thompson @ 1999-08-18 0:00 UTC (permalink / raw) tmoran@bix.com writes: > > If an implementation doesn't provide garbage collection then that > > storage is forever lost, is that correct? > > No. When the access type goes out of scope there is clearly no way > the storage can be on the target end of a pointer, so the > implementation should free that storage. Just to clarify, most implementations don't actually do this. Thus, under most Ada implementations, storage *will* be "forever lost" if you allocate it and don't explicitly deallocate it. (Well, "forever" usually means "until the program terminates".) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` Keith Thompson @ 1999-08-19 0:00 ` Tucker Taft 1999-08-19 0:00 ` Robert Dewar 1999-08-19 0:00 ` Robert Dewar 1999-08-20 0:00 ` tmoran 1 sibling, 2 replies; 28+ messages in thread From: Tucker Taft @ 1999-08-19 0:00 UTC (permalink / raw) Keith Thompson wrote: > > tmoran@bix.com writes: > > > If an implementation doesn't provide garbage collection then that > > > storage is forever lost, is that correct? > > > > No. When the access type goes out of scope there is clearly no way > > the storage can be on the target end of a pointer, so the > > implementation should free that storage. > > Just to clarify, most implementations don't actually do this. Thus, > under most Ada implementations, storage *will* be "forever lost" if > you allocate it and don't explicitly deallocate it. (Well, "forever" > usually means "until the program terminates".) In Ada 95, implementations are required to reclaim the storage associated with an access type if the 'Storage_Size attribute is specified (which Tom also mentioned, by the way). If no 'Storage_Size is specified, then you are correct that most Ada 95 compilers don't reclaim the storage automatically when leaving the scope of the access type. > -- > Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> > San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> > One of the great tragedies of ancient history is that Helen of Troy > lived before the invention of the champagne bottle. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-19 0:00 ` Tucker Taft @ 1999-08-19 0:00 ` Robert Dewar 1999-08-19 0:00 ` Robert Dewar 1 sibling, 0 replies; 28+ messages in thread From: Robert Dewar @ 1999-08-19 0:00 UTC (permalink / raw) In article <37BC2203.328E6338@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Keith Thompson wrote: > > > > tmoran@bix.com writes: > > > > If an implementation doesn't provide garbage collection then that > > > > storage is forever lost, is that correct? > > > > > > No. When the access type goes out of scope there is clearly no way > > > the storage can be on the target end of a pointer, so the > > > implementation should free that storage. > > > > Just to clarify, most implementations don't actually do this. Thus, > > under most Ada implementations, storage *will* be "forever lost" if > > you allocate it and don't explicitly deallocate it. (Well, "forever" > > usually means "until the program terminates".) > > In Ada 95, implementations are required to reclaim the storage associated > with an access type if the 'Storage_Size attribute is specified (which > Tom also mentioned, by the way). If no 'Storage_Size is specified, then > you are correct that most Ada 95 compilers don't reclaim the storage > automatically when leaving the scope of the access type. Ada compilers have differed here. The old Alsys compilers always used to automatically free local access stuff on exit. The trouble is that people are quite used to controlling this memory manually, and in this case you do add quite a bit of overhead by arranging for the automatic release. We went backwards and forwards on what the default should be in GNAT, and decided finally that the default was not to free this storage, however, it is trivial to specify that the space for a local access collection SHOULD be freed on access by using: for access_type_name'Storage_Pool use System.Pool_Local.Unbounded_Reclaim_Pool; Probably a good idea would be to add a configuration pragma that made this pool assignment the default. By the way, a recommendation is to look through the collection of storage pool implementations provided in GNAT, there is a lot of useful functionality there, including a very useful debug pool that checks for correct storage handling. P.S. Ada 83 also required that access types with an explicit storage size be freed on scope exit. The Ada 83 RM strongly suggests that this should be the default for all access types, but stops short of requiring this. Even the implication is removed from the Ada 95 RM. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-19 0:00 ` Tucker Taft 1999-08-19 0:00 ` Robert Dewar @ 1999-08-19 0:00 ` Robert Dewar 1 sibling, 0 replies; 28+ messages in thread From: Robert Dewar @ 1999-08-19 0:00 UTC (permalink / raw) In article <37BC2203.328E6338@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Keith Thompson wrote: > > > > tmoran@bix.com writes: > > > > If an implementation doesn't provide garbage collection then that > > > > storage is forever lost, is that correct? > > > > > > No. When the access type goes out of scope there is clearly no way > > > the storage can be on the target end of a pointer, so the > > > implementation should free that storage. > > > > Just to clarify, most implementations don't actually do this. Thus, > > under most Ada implementations, storage *will* be "forever lost" if > > you allocate it and don't explicitly deallocate it. (Well, "forever" > > usually means "until the program terminates".) > > In Ada 95, implementations are required to reclaim the storage associated > with an access type if the 'Storage_Size attribute is specified (which > Tom also mentioned, by the way). If no 'Storage_Size is specified, then > you are correct that most Ada 95 compilers don't reclaim the storage > automatically when leaving the scope of the access type. Ada compilers have differed here. The old Alsys compilers always used to automatically free local access stuff on exit. The trouble is that people are quite used to controlling this memory manually, and in this case you do add quite a bit of overhead by arranging for the automatic release. We went backwards and forwards on what the default should be in GNAT, and decided finally that the default was not to free this storage, however, it is trivial to specify that the space for a local access collection SHOULD be freed on access by using: for access_type_name'Storage_Pool use System.Pool_Local.Unbounded_Reclaim_Pool; Probably a good idea would be to add a configuration pragma that made this pool assignment the default. By the way, a recommendation is to look through the collection of storage pool implementations provided in GNAT, there is a lot of useful functionality there, including a very useful debug pool that checks for correct storage handling. P.S. Ada 83 also required that access types with an explicit storage size be freed on scope exit. The Ada 83 RM strongly suggests that this should be the default for all access types, but stops short of requiring this. Even the implication is removed from the Ada 95 RM. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Tucker Taft @ 1999-08-20 0:00 ` tmoran 1999-08-20 0:00 ` Keith Thompson 1999-08-21 0:00 ` Robert Dewar 1 sibling, 2 replies; 28+ messages in thread From: tmoran @ 1999-08-20 0:00 UTC (permalink / raw) > > No. When the access type goes out of scope there is clearly no way > > the storage can be on the target end of a pointer, so the > > implementation should free that storage. > > Just to clarify, most implementations don't actually do this. Why? Is an implementation not easy, efficient, and predictable? And of course overidable by the user simply by raising the level where the access type is declared. It seems undesirable to have to specify a number, big enough, but not too big, for the amount of storage needed when you merely want to get automatic deallocation. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` tmoran @ 1999-08-20 0:00 ` Keith Thompson 1999-08-20 0:00 ` Matthew Heaney 1999-08-21 0:00 ` garbage collection Brian Rogoff 1999-08-21 0:00 ` Robert Dewar 1 sibling, 2 replies; 28+ messages in thread From: Keith Thompson @ 1999-08-20 0:00 UTC (permalink / raw) tmoran@bix.com writes: > > > No. When the access type goes out of scope there is clearly no way > > > the storage can be on the target end of a pointer, so the > > > implementation should free that storage. > > > > Just to clarify, most implementations don't actually do this. > Why? Is an implementation not easy, efficient, and predictable? > And of course overidable by the user simply by raising the > level where the access type is declared. > It seems undesirable to have to specify a number, big enough, but > not too big, for the amount of storage needed when you merely want > to get automatic deallocation. I just realized that I had mis-read the article to which I was responding. What "most implementations don't actually do" is general garbage collection, i.e., freeing allocated memory after it becomes inaccessible. Freeing allocated memory when leaving the scope of an access type is much easier. I *think* that most implementations don't even do this, but I'm not as sure on this point. It does impose a little extra overhead, in both time and space. Specifying the 'Storage_Pool attribute is a very powerful and under-used feature, IMHO. The biggest obstacle to its use, I suspect, is the need to implement the Storage_Pool operations. If System.Storage_Pools also provided routines for dereferencing access values (perhaps one each for reading and writing), and perhaps also for initialization and finalization of access objects, it would be even more powerful. I haven't entirely thought this through, so it may be a bad idea for some reason. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Keith Thompson @ 1999-08-20 0:00 ` Matthew Heaney 1999-08-20 0:00 ` Keith Thompson ` (2 more replies) 1999-08-21 0:00 ` garbage collection Brian Rogoff 1 sibling, 3 replies; 28+ messages in thread From: Matthew Heaney @ 1999-08-20 0:00 UTC (permalink / raw) In article <yecwvuqhrkx.fsf@king.cts.com> , Keith Thompson <kst@cts.com> wrote: > Specifying the 'Storage_Pool attribute is a very powerful and > under-used feature, IMHO. The biggest obstacle to its use, I suspect, > is the need to implement the Storage_Pool operations. One thing I miss is not having a set of nameable, pre-defined storage pools. You have that in GNAT, but it's not really portable because of certain low-level calls (to a C routine called "_gnat__allocate", or something like that). > If System.Storage_Pools also provided routines for dereferencing > access values (perhaps one each for reading and writing), and perhaps > also for initialization and finalization of access objects, it would > be even more powerful. I haven't entirely thought this through, so it > may be a bad idea for some reason. That's one nice thing about C++. You can implement a pointer abstraction that has a syntax identical to a built-in pointer. In Ada95, you have to implement a "handle" type that provides a dereference operator: type T (<>) is limited private; type T_Access is access all T; type T_Handle is private; function "+" (Handle : T_Handle) return T_Access; All the primitive operations of T take access parameters, since we're always dealing with pointers to T: procedure Op (O : access T); function Get_Attribute (O : access T) return Attr_T; You also have constructor(s) that return a handle object: function New_T return T_Handle; -- not T_Access All the actual garbage collection is associated with T_Handle, since there's no way to do that with the access type T_Access directly. (Which is how Ada95 differs from C++.) I use this technique to implement reference-counting for on-the-heap abstractions, so that when the count drops to zero the memory is automatically reclaimed. See the patterns archives for lots of examples. <http://www.acm.org/archives/patterns.html> The only trap door in this scheme is that there's no way to prevent the client from manipulating the access object directly, say, by making a copy. It has to be understood by users that that is something you never do with a handle-based abstraction. It would be swell if the language were amended to make access types limited; this would prevent any problems engendered by accidental copying of access objects. -- Matt It is impossible to feel great confidence in a negative theory which has always rested its main support on the weak points of its opponent. Joseph Needham, "A Mechanistic Criticism of Vitalism" ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Matthew Heaney @ 1999-08-20 0:00 ` Keith Thompson 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Matthew Heaney 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` garbage collection [storage pools] Robert Dewar 2 siblings, 2 replies; 28+ messages in thread From: Keith Thompson @ 1999-08-20 0:00 UTC (permalink / raw) "Matthew Heaney" <matthew_heaney@acm.org> writes: [...] > It would be swell if the language were amended to make access types limited; > this would prevent any problems engendered by accidental copying of access > objects. Not all access types, I hope; sometimes you do want to copy access values! -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Keith Thompson @ 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Matthew Heaney 1999-08-21 0:00 ` Matthew Heaney 1 sibling, 1 reply; 28+ messages in thread From: Robert Dewar @ 1999-08-21 0:00 UTC (permalink / raw) In article <yecvha9izs6.fsf@king.cts.com>, > "Matthew Heaney" <matthew_heaney@acm.org> writes: > [...] > > It would be swell if the language were amended to make access types limited; > > this would prevent any problems engendered by accidental copying of access > > objects. There has *got* to be a smiley missing here. It is inconceivable to make this change to the language (all access types limited) and would be HIGHLY undesirable. Presumably, if the above is not a joke (which it might be, I am not sure), it is a proposal for some kind of extension involving limited access types. Actually I think the reasonable thing to do is to extend the storage pool abstraction so that a version of it contains a copy operation that is called for all implicit copies of the given access value. You probably want to introduce some general controlled notion here. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-21 0:00 ` Robert Dewar @ 1999-08-21 0:00 ` Matthew Heaney 0 siblings, 0 replies; 28+ messages in thread From: Matthew Heaney @ 1999-08-21 0:00 UTC (permalink / raw) In article <7pmad9$jnq$1@nnrp1.deja.com> , Robert Dewar <robert_dewar@my-deja.com> wrote: >>> It would be swell if the language were amended to make access types limited; >>> this would prevent any problems engendered by accidental copying of access >>> objects. > > There has *got* to be a smiley missing here. It is inconceivable > to make this change to the language (all access types limited) > and would be HIGHLY undesirable. Oh dear, I seemed to have confused people. No, I certainly don't mean make *all* access types limited. Only those access types specifically marked as limited, a la limited record types. > Presumably, if the above is not a joke (which it might be, > I am not sure), it is a proposal for some kind of extension > involving limited access types. Yes, it is a proposal for an extension involving limited access types. > Actually I think the reasonable thing to do is to extend the > storage pool abstraction so that a version of it contains > a copy operation that is called for all implicit copies of > the given access value. You probably want to introduce some > general controlled notion here. That would be really slick: being able to make access types controlled directly, instead of having to wrap the access object in a some kind of controlled abstraction (what I usually call a "handle"). -- Matt It is impossible to feel great confidence in a negative theory which has always rested its main support on the weak points of its opponent. Joseph Needham, "A Mechanistic Criticism of Vitalism" ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Keith Thompson 1999-08-21 0:00 ` Robert Dewar @ 1999-08-21 0:00 ` Matthew Heaney 1 sibling, 0 replies; 28+ messages in thread From: Matthew Heaney @ 1999-08-21 0:00 UTC (permalink / raw) In article <yecvha9izs6.fsf@king.cts.com> , Keith Thompson <kst@cts.com> wrote: > "Matthew Heaney" <matthew_heaney@acm.org> writes: > [...] >> It would be swell if the language were amended to make access types limited; >> this would prevent any problems engendered by accidental copying of access >> objects. > > Not all access types, I hope; sometimes you do want to copy access > values! Yes, of course. Something like: type T_Access is limited access all T; This proposal has also been bandied about for another reason: it has been proffered as part of the solution to the problem of not being able to take the 'Access of a local subprogram. -- Matt It is impossible to feel great confidence in a negative theory which has always rested its main support on the weak points of its opponent. Joseph Needham, "A Mechanistic Criticism of Vitalism" ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Matthew Heaney 1999-08-20 0:00 ` Keith Thompson @ 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` garbage collection [storage pools] Robert Dewar 2 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1999-08-21 0:00 UTC (permalink / raw) In article <37be0c85@news1.us.ibm.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > That's one nice thing about C++. You can implement a pointer > abstraction that has a syntax identical to a built-in pointer. > In Ada95, you have to implement a "handle" type that provides > a dereference operator: Not in GNAT, simply derive from the Checked_Pool abstraction, providing an appropriate Dereference function. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection [storage pools] 1999-08-20 0:00 ` Matthew Heaney 1999-08-20 0:00 ` Keith Thompson 1999-08-21 0:00 ` Robert Dewar @ 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Simon Wright 2 siblings, 1 reply; 28+ messages in thread From: Robert Dewar @ 1999-08-21 0:00 UTC (permalink / raw) In article <37be0c85@news1.us.ibm.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > One thing I miss is not having a set of nameable, pre-defined > storage pools. > You have that in GNAT, but it's not really portable because of > certain > low-level calls (to a C routine called "_gnat__allocate", or > something like > that). Well it is unlikely that implementations of storage pools will be completely portable in any case, because they will undoubtedly do implementation defined stuff using unchecked conversions, address arithmetic, calls to library routines etc. So it is probably not a good idea to try to insist on portable implementations. It would be VERY nice to have a standard set of storage pools with standard interfaces. This is an excellent area to suggest to the ARG for future standardization. In GNAT, we provide the following Stack_Bounded_Pool really intended only for internal use, implements the allocation strategy for fixed size objects when a storage size clause is present. Unbounded_No_Reclaim_Pool again really intended for internal use, this is the default storage pool that simply allocates from the heap Unbounded_Reclaim_Pool this is the one that I have mentioned before, it provides a local allocation capability where the objects are all freed automatically on scope exit Checked_Pool this is like the standard unbounded no reclaim pool, but has a dereference procedure that is called on each dereference of an object in the pool. This is still an abstract pool, the user must specialize it with an appropriate extension to provide a useful definition for dereference. This is really a language extension (of the allowed kind, provided by a package). Debug_Pool this is like the standard unbounded no reclaim pool, but it maintains extra overhead to do full validity checking on all operations. This is useful for tracking down storage leaks. One can think of many more useful pools, most notably one that provides defined worst case bounded time performance for real time use. It would also be useful to standardize a pragma to override the normal default storage pool (we plan adding such a pragma to the next version of GNAT). Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection [storage pools] 1999-08-21 0:00 ` garbage collection [storage pools] Robert Dewar @ 1999-08-21 0:00 ` Simon Wright 0 siblings, 0 replies; 28+ messages in thread From: Simon Wright @ 1999-08-21 0:00 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > It would be VERY nice to have a standard set of storage pools > with standard interfaces. This is an excellent area to suggest > to the ARG for future standardization. I would strongly support this idea. -- Simon Wright Work Email: simon.j.wright@gecm.com Alenia Marconi Systems Voice: +44(0)1705-701778 Integrated Systems Division FAX: +44(0)1705-701800 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Keith Thompson 1999-08-20 0:00 ` Matthew Heaney @ 1999-08-21 0:00 ` Brian Rogoff 1 sibling, 0 replies; 28+ messages in thread From: Brian Rogoff @ 1999-08-21 0:00 UTC (permalink / raw) On 20 Aug 1999, Keith Thompson wrote: > Specifying the 'Storage_Pool attribute is a very powerful and > under-used feature, IMHO. The biggest obstacle to its use, I suspect, > is the need to implement the Storage_Pool operations. > > If System.Storage_Pools also provided routines for dereferencing > access values (perhaps one each for reading and writing), and perhaps > also for initialization and finalization of access objects, it would > be even more powerful. I haven't entirely thought this through, so it > may be a bad idea for some reason. See a discussion of this in comp.lang.ada, Nov '96, in a thread named "Garbage Collection in Ada". -- Brian ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` tmoran 1999-08-20 0:00 ` Keith Thompson @ 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Default Storage Pool (was Re: garbage collection) Simon Wright 1 sibling, 1 reply; 28+ messages in thread From: Robert Dewar @ 1999-08-21 0:00 UTC (permalink / raw) In article <vvhv3.214$36.49923@typhoon-sf.snfc21.pbi.net>, tmoran@bix.com wrote: > > Just to clarify, most implementations don't actually do > > this. > Why? Is an implementation not easy, efficient, > and predictable? Easy: fairly so, look at System.Pool_Local in the GNAT sources (s-pooloc.ads). Not that complex. The body is 189 lines, perhaps only 60 lines or so of actual code. Predictable: sure Efficient: there's the rub, there is significant overhead from arranging for the automatic release, both in space and time. We found that most existing code does NOT assume this automatic release, and it clearly makes no sense to use this pool by default if the program does all its own deallocation. > And of course overidable by the user simply by raising the > level where the access type is declared. > It seems undesirable to have to specify a number, big enough, but > not too big, for the amount of storage needed when you merely want > to get automatic deallocation. No, that's not the way to do it (using Storage_Size). Only use a Storage_Size where it really does make sense to allocate in a fixed length area on the stack. Instead use a storage pool. If you are using GNAT, just do for this_access_type'Storage_Pool use System.Pool_Local.Unbounded_Reclaim_Pool; and of course do a "with" of System.Pool_Local. If you are using some other compiler that does not provide this very useful capability, then you need to write your own storage pool implementation (the one with GNAT may work, but you can't assume that library routines supplied with GNAT will work unchanged with other compilers (*) since they may depend on GNAT specific features -- I don't know if this one does or not). Robert Dewar Ada Core Technologies (*) People sometimes make the mistake of assuming that because the GNAT runtime is written in Ada, it can automatically be used with other compilers. Sometimes this is the case (indeed one other vendor was routinely supplying some of the GNAT math routines for a while, to plug holes in their own run-time, they may still do this, I don't know ...) But on the other hand, sales folks for that same vendor were telling people: "DOn't worry about the information systems annex, we don't provide it, but if you need it, you can just pick up the GNAT routines and use them with our compiler." Unfortunately that is definitely not the case. In the first place, the underlying compiler must support 18-digit decimal scaled arithmetic. Secondly, the implementation relies on GNAT specific stuff, e.g. procedure Divide (Dividend : in Dividend_Type; Divisor : in Divisor_Type; Quotient : out Quotient_Type; Remainder : out Remainder_Type) is -- We have a nested procedure that is the actual -- intrinsic divide. -- This is required because in the current RM, Divide -- itself does -- not have convention Intrinsic. procedure Divide (Dividend : in Dividend_Type; Divisor : in Divisor_Type; Quotient : out Quotient_Type; Remainder : out Remainder_Type); pragma Import (Intrinsic, Divide); begin Divide (Dividend, Divisor, Quotient, Remainder); end Divide; Now it would be possible to implement a non-intrinsic divide, but it would be gruesomely inefficient. This is simply a divide operation, and really needs to be specialized by the compilers code generator. Trying to do this with portable Ada is just at the wrong level! Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Default Storage Pool (was Re: garbage collection) 1999-08-21 0:00 ` Robert Dewar @ 1999-08-21 0:00 ` Simon Wright 1999-08-23 0:00 ` Robert A Duff 0 siblings, 1 reply; 28+ messages in thread From: Simon Wright @ 1999-08-21 0:00 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > for this_access_type'Storage_Pool > use System.Pool_Local.Unbounded_Reclaim_Pool; > > and of course do a "with" of System.Pool_Local. > > If you are using some other compiler that does not provide this > very useful capability, then you need to write your own storage > pool implementation (the one with GNAT may work, but you can't > assume that library routines supplied with GNAT will work > unchanged with other compilers (*) since they may depend on > GNAT specific features -- I don't know if this one does or not). It would have been very helpful for the Booch Components if all compilers provided a (standardised, if at all possible) mechanism to access their default Storage Pool. We had to muck around with indirect means of finding it, which triggered problems in several compilers. (BTW, Unbounded_Reclaim_Pool extends Unbounded_No_Reclaim_Pool which uses gnat_malloc, gnat_free so there would be some work to do to use them with another compiler -- 3.11p) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Default Storage Pool (was Re: garbage collection) 1999-08-21 0:00 ` Default Storage Pool (was Re: garbage collection) Simon Wright @ 1999-08-23 0:00 ` Robert A Duff 0 siblings, 0 replies; 28+ messages in thread From: Robert A Duff @ 1999-08-23 0:00 UTC (permalink / raw) Simon Wright <simon@pogner.demon.co.uk> writes: > It would have been very helpful for the Booch Components if all > compilers provided a (standardised, if at all possible) mechanism to > access their default Storage Pool. There is no requirement that the compiler only have one default pool. But you can say: type T1 is access ...; ... type T2 is access ...; for T2'Storage_Pool use T1'Storage_Pool; - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 garbage collection Ronald Ayoub 1999-08-18 0:00 ` tmoran @ 1999-08-18 0:00 ` Gisle S�lensminde 1999-08-18 0:00 ` Pascal MALAISE 1999-08-18 0:00 ` Robert I. Eachus 3 siblings, 0 replies; 28+ messages in thread From: Gisle S�lensminde @ 1999-08-18 0:00 UTC (permalink / raw) In article <7pe93j$ehg$1@dailyplanet.wam.umd.edu>, Ronald Ayoub wrote: >In the book "Programming in Ada 95" by Barnes he says: > >If an allocated object becomes inaccessbile becasue no declard objects refer >to it directly or indirectly then the storage it occupies may be reclaimed >so that it can be reused for other objects. An implementation may (but need >not) provide garbage collection for this. > >I need this to be clarified for me. If an implementation doesn't provide >garbage collection then that storage is forever lost, is that correct? Or >does this mean that it may not be garbage collected but when a call to new >is executed it is at that time scene as available. Please clarify. This seems >like a real bad idea not to have some form of garbage collection inforced. > >Ron This is one of the strange things with Ada. Nearly all textbooks are giving you the impression that garbage collection is common in Ada compilers, and that maybe some compilers not has implemented GC, since the standard allows an implemention to not implement it. The fact is that hardly any Ada compilers have GC. The only ones I know about is those targeted for java virtual machine bytecode, where the virtual machine implements GC. (appletmagic and soon? jgnat) The reason is of cause that GC not is desireable for most realtime systems, which is the traditional area for Ada, but for many other tasks, GC is a good thing. However, I miss GC less in Ada then in many other languages, because you are less dependent on dynamic memory then in most other languages, and controlled types can be used to automaticly free memory when they goes out of scope or are assigned to. -- Gisle S�lensminde ( gisle@ii.uib.no ) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 garbage collection Ronald Ayoub 1999-08-18 0:00 ` tmoran 1999-08-18 0:00 ` garbage collection Gisle S�lensminde @ 1999-08-18 0:00 ` Pascal MALAISE 1999-08-20 0:00 ` David Botton 1999-08-18 0:00 ` Robert I. Eachus 3 siblings, 1 reply; 28+ messages in thread From: Pascal MALAISE @ 1999-08-18 0:00 UTC (permalink / raw) Ronald Ayoub wrote: ... > If an implementation doesn't provide > garbage collection then that storage is forever lost, is that correct? Or > does this mean that it may not be garbage collected but when a call to new > is executed it is at that time scene as available. Please clarify. This seems > like a real bad idea not to have some form of garbage collection inforced. The most portable approach is not to depend on a potential garbage collector in the runtime and keep a free list of unused chunks. With this mecanism a process has at least a measurable and maximum (even if not optimized) virtual size. -- Allocates and frees cells of data access, -- using a free list to re-use free cells. generic type DATA_TYPE is private; type DATA_ACCESS_TYPE is access DATA_TYPE; package DYN_DATA is -- Allocates a new cell. -- The result is the access to a pre allocated area for DATA_TYPE. function ALLOCATE return DATA_ACCESS_TYPE; -- Allocates a new cell and fills it with DATA -- The result is the access to a pre allocated area for DATA_TYPE, -- storing DATA function ALLOCATE (DATA : DATA_TYPE) return DATA_ACCESS_TYPE; -- Frees a cell. DATA_ACCESS is set to null. procedure FREE (DATA_ACCESS : in out DATA_ACCESS_TYPE); end DYN_DATA; 6 ada instructions. Body available on request. It does not depend on any package and has 37 ada instructions :-) Of course, if you claim some chunks and release them, then claim for other chunks of another type (even the same size), some new data is allocated that a garbage collector would have re-used. That's the drawback. But the old chucks are only swap usage, aren't they? -- Pascal MALAISE (priv) mailto:malaise@magic.fr (prof) mailto:malaise@fr.airsysatm.thomson-csf.com ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` Pascal MALAISE @ 1999-08-20 0:00 ` David Botton 0 siblings, 0 replies; 28+ messages in thread From: David Botton @ 1999-08-20 0:00 UTC (permalink / raw) Perhaps send the package to AdaSource@AdaPower.com and make your code available to the world :) David Botton Pascal MALAISE wrote in message <37BAFA16.3138228B@magic.fr>... >6 ada instructions. >Body available on request. It does not depend on any package and has 37 >ada instructions :-) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 garbage collection Ronald Ayoub ` (2 preceding siblings ...) 1999-08-18 0:00 ` Pascal MALAISE @ 1999-08-18 0:00 ` Robert I. Eachus 1999-08-19 0:00 ` Gautier 1999-08-20 0:00 ` Keith Thompson 3 siblings, 2 replies; 28+ messages in thread From: Robert I. Eachus @ 1999-08-18 0:00 UTC (permalink / raw) Ronald Ayoub wrote: > I need this to be clarified for me. If an implementation doesn't provide > garbage collection then that storage is forever lost, is that correct? Or > does this mean that it may not be garbage collected but when a call to new > is executed it is at that time scene as available. Please clarify. This seems > like a real bad idea not to have some form of garbage collection inforced. The correct answer is c) All Ada compilers provide some forms of storage management, and most Ada programs lose no storage. But very few Ada implementations support compacting garbage collectors. I could go into all the gory details, but that about sums it up. The validation tests do include several tests to insure that storage is not lost in many common situations, but there is no requirement that storage be freed the moment their are no more references. Many Ada compilers instead free the storage when the access type goes out of scope for some or all types. Why? Three reasons. Freeing the storage when the type goes out of scope allows for predictable storage reclamation which is very useful in real-time code. Second, the user can easily manage storage for any type the way he wants to. Insisting on "full" garbage collection would limit the user's choices. And finally, Ada allows return values from functions which are unbounded, and for which the storage is "automagically" managed. If you define a function which returns a string in Ada, there is no need for explicit alloc and free calls or the equivalent. So in ninety percent or more of the cases where you need garbage collection in other languages, you don't even need explicit allocations in Ada. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` Robert I. Eachus @ 1999-08-19 0:00 ` Gautier 1999-08-19 0:00 ` Robert I. Eachus 1999-08-20 0:00 ` Keith Thompson 1 sibling, 1 reply; 28+ messages in thread From: Gautier @ 1999-08-19 0:00 UTC (permalink / raw) > Why? Three reasons. Freeing the storage when the type goes out of > scope allows for predictable storage reclamation which is very useful in > real-time code. Second, the user can easily manage storage for any type > the way he wants to. Insisting on "full" garbage collection would limit > the user's choices. BTW: is it possible to prove that an object is not more accessed (of course: as long as its type exists) ? It's so easy to copy a pointer... -- Gautier ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-19 0:00 ` Gautier @ 1999-08-19 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 28+ messages in thread From: Robert I. Eachus @ 1999-08-19 0:00 UTC (permalink / raw) > BTW: is it possible to prove that an object is not more accessed > (of course: as long as its type exists) ? It's so easy to copy a pointer... Which is why Ada has access types instead. ;-) Seriously, if an access type goes out of scope, then it is legitimate to recover all storage associated with the type. If you have gone and done something like using Unchecked_Conversion to convert to a different access type, well, you asked for it. (You can get into similar trouble by saving addresses. The whole idea is that access types are safe as long as you don't go outside the rules. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-18 0:00 ` Robert I. Eachus 1999-08-19 0:00 ` Gautier @ 1999-08-20 0:00 ` Keith Thompson 1999-08-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 28+ messages in thread From: Keith Thompson @ 1999-08-20 0:00 UTC (permalink / raw) "Robert I. Eachus" <eachus@mitre.org> writes: [...] > I could go into all the gory details, but that about sums it up. The > validation tests do include several tests to insure that storage is not > lost in many common situations, but there is no requirement that storage > be freed the moment their are no more references. Many Ada compilers > instead free the storage when the access type goes out of scope for some > or all types. > > Why? Three reasons. Freeing the storage when the type goes out of > scope allows for predictable storage reclamation which is very useful in > real-time code. Second, the user can easily manage storage for any type > the way he wants to. Insisting on "full" garbage collection would limit > the user's choices. [...] BTW, in my experience most access types don't go out of scope until the program terminates, because they're declared in library-level packages. The automated reclamation can only take place if the access type is declared directly or indirectly within a subprogram or a task body (there may be other cases). (I'm not sure how typical my experience is; how common is it to declare an access type within a subprogram?) Note that declaring an access *object* within a subprogram doesn't let the storage it refers to be reclaimed; the access value could have been copied to an object in an outer scope before the subprogram completed. > And finally, Ada allows return values from functions which are > unbounded, and for which the storage is "automagically" managed. If you > define a function which returns a string in Ada, there is no need for > explicit alloc and free calls or the equivalent. So in ninety percent > or more of the cases where you need garbage collection in other > languages, you don't even need explicit allocations in Ada. Right, I think this is the biggest reason that the lack of garbage collection in most Ada implementations isn't (much of) a problem. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: garbage collection 1999-08-20 0:00 ` Keith Thompson @ 1999-08-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 28+ messages in thread From: Robert Dewar @ 1999-08-20 0:00 UTC (permalink / raw) In article <yec9076vqly.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > BTW, in my experience most access types don't go out of scope > until > the program terminates, because they're declared in > library-level > packages. The automated reclamation can only take place if > the access > type is declared directly or indirectly within a subprogram or > a task > body (there may be other cases). True, but the one familiar case in which access types are declared locally is *precisely* when you want to take advantage of the compiler being able to free everything on scope exit. Of course you have to make sure that your compiler has this capability (GNAT does, I don't know about other Ada 95 compilers). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~1999-08-23 0:00 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-08-18 0:00 garbage collection Ronald Ayoub 1999-08-18 0:00 ` tmoran 1999-08-18 0:00 ` Keith Thompson 1999-08-19 0:00 ` Tucker Taft 1999-08-19 0:00 ` Robert Dewar 1999-08-19 0:00 ` Robert Dewar 1999-08-20 0:00 ` tmoran 1999-08-20 0:00 ` Keith Thompson 1999-08-20 0:00 ` Matthew Heaney 1999-08-20 0:00 ` Keith Thompson 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Matthew Heaney 1999-08-21 0:00 ` Matthew Heaney 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` garbage collection [storage pools] Robert Dewar 1999-08-21 0:00 ` Simon Wright 1999-08-21 0:00 ` garbage collection Brian Rogoff 1999-08-21 0:00 ` Robert Dewar 1999-08-21 0:00 ` Default Storage Pool (was Re: garbage collection) Simon Wright 1999-08-23 0:00 ` Robert A Duff 1999-08-18 0:00 ` garbage collection Gisle S�lensminde 1999-08-18 0:00 ` Pascal MALAISE 1999-08-20 0:00 ` David Botton 1999-08-18 0:00 ` Robert I. Eachus 1999-08-19 0:00 ` Gautier 1999-08-19 0:00 ` Robert I. Eachus 1999-08-20 0:00 ` Keith Thompson 1999-08-20 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox