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,5997b4b7b514f689 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Reading a line of arbitrary length Date: 1997/03/05 Message-ID: #1/1 X-Deja-AN: 223295703 References: <5ds40o$rpo@fg70.rz.uni-karlsruhe.de> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-03-05T00:00:00+00:00 List-Id: In article , Jon S Anthony wrote: >In article dewar@merv.cs.nyu.edu (Robert Dewar) writes: > >> Jon said >> >> <> "transparent". That it should have some explicit programmer control >> available.>> >> >> Well there is a contentions statement. I strongly disagree that GC >> should not be simply transparent, and I do not like the idea of >> standardizing explicit programmer control, whatever that might be. > >Yes, it is. These are merely points that have been made in GC >circles. I'm not _advocating_ them, just trying to point out various >reason why a "defined standard minimal interface" may be needed. Well, there are lots of useful performance-tuning hooks that are supported by many existing garbage collectors. If one were standardizing the existence of GC, it's not clear whether (some) such hooks should be standardized as well. Probably performance-tuning hooks are "transparent" in Robert's view, and I would agree, but the programmer would still like to know how to spell the "Please GC now" command, for example. There are some interesting interactions between finalization and GC. The simplest answer is that any object with controlled parts is "live", so the GC can't collect it. But that's not what people want, I think. At least not all the time. (Maybe only for non-limited controlled things?) People probably want the GC to finalize things just before reclaiming their storage. But this opens up various issues: What if the Finalize routine takes an otherwise-dead object, and resurrects it by planting a pointer to it somewhere? What if the Finalize routine calls a non-reentrant procedure, and the GC decides to call Finalize at an embarrassing time? Are there any constraints on the order in which Finalize routines get called in a case where several heap objects become dead at the same time? A standard for a GC'ed Ada would certainly need to address these issues. Somebody else mentioned the other area in which GC is not transparent: interfacing to other languages. Garbage collection is a global problem, so if just one small part of your program is written in, say, C, then the programmer needs to know whose responsibility it is to deal with pointers from the C side to the Ada side. Is the GC conservative? Or does the user have to ensure that any such pointer is duplicated on the Ada side? The above is talking about an imaginary universe in which Ada 95 requires garbage collection. There's also the issue of what it means to "require" GC -- one would need a much more specific (and complicated) model of storage usage. Or else one would need to rely on untestable "requirements", which has worked fine for Lisp and Eiffel and lots of others. - Bob