From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3498dd887729ed19 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Garbage Collection in Ada Date: 1996/10/23 Message-ID: <54kjat$hpn$1@goanna.cs.rmit.EDU.AU>#1/1 X-Deja-AN: 191446063 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> <19961015122319668722@dialup98-6-12.swipnet.se> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-10-23T00:00:00+00:00 List-Id: dewar@merv.cs.nyu.edu (Robert Dewar) writes: >The problem is that it is all too easy to have a global variable around >that accidentally holds on to a giant structure. It is also easy to do this with manual allocation. The practical issue that _I_ see here is that garbage collection enables "storage profiling" where you can _ask_ "what storage is being held onto and why?". There was a very nice paper about a garbage profiling published in PLDI 96 (I _think_ that was the conference). Garbage profiling is a valuable development tool, just like time profiling, and I hope it is soon adopted in many systems. In a system which achieves economies (if such economies exist) by not doing garbage collection, it is much harder to provide such facilities. You can indeed ask where the currently retained blocks were _allocated_ (or at least you can in the memory debugging library I use for C), but you can't ask "_why_ is this block retained?" So the bottom line is that when you consider the whole lifecycle instead of just a single run, garbage collection PLUS garbage profiling is a better bet than relying on the programmer to be perfect. >Or for example, depending >on your implementation, taking the 'Access of one field of one record in >some big structure may end up holding on to an entire subgraph that you >do not need. And again, in a manually managed system, exactly the same situation can arise, and the programmer may not dare to free the storage manually because the analysis to prove it safe statically is too hard (or in the case of someone else's code receiving the 'Access), impossible. And again, garbage profiling can help with this, whereas no-support-for-gc means in practice no support for garbage profiling either. >You may in practice need to be just as careful about adding > Junk := null; >statements to your program as you are now about adding > Free (Junk); >statements to your program now. This seems unlikely, because the former is a *local* decision, that *this* reference is no longer needed, while the latter is a *global* decision, that *all* references are no longer needed. I would very much like to see LCLint-style memory checking in a tool for Ada. >GC is certainly a magic bullet solution to the problem of accidentally >freeing storage that should not be freed, but it is NOT a magic bullet >with respect to not freeing things that should be freed. But it *is* half of the magic bullet. The other half is garbage profiling, which requires at least the same hooks as garbage collection. If you are concerned about the memory use of your program, you want to know - which objects are being retained after their last real use - and which references are keeping the dead blocks around It _is_ possible to build a development tool for manual management that tells you which objects are being retained after their last real use (trace allocation, deallocation, loads, and stores, then inspect the trace). But the other half you need is _why_ the objects are being retained after their last use. >People who >approach a GC language environment with this expectation will be >disappointed! This is not an argument *against* automatic garbage collection, it is an argument *for* garbage profiling. -- Mixed Member Proportional---a *great* way to vote! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.