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: Rick Hudson Subject: Re: Garbage Collection in Ada Date: 1996/10/17 Message-ID: #1/1 X-Deja-AN: 190147528 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> organization: Dept of Comp Sci, Univ of Mass (Amherst) newsgroups: comp.lang.ada Date: 1996-10-17T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: > > In article <3265BD97.41C6@mti.sgi.com>, > Hans-Juergen Boehm wrote: > >For systems I've seen it does inhibit some optimizations, ar least to > >the extent that proper use of a conservative collector inhibits > >optimizations. Especially in multithreaded systems, there must be a > >recognizable pointer to every accessible object at every program point > >at which a GC might occur. Often this is between every pair of > >instructions. In a nonconservative system you could generate > >arbitrarily complex tables to allow reconstruction of those pointers. You could but you don't have to. If GC is triggered only by an allocate then one could roll forward the threads to a 'gc' point. This greatly reduces the amount of table information needed. > > I would think it would be simpler and more efficient to represent this > information as executable code. That is, the compiler generates a > procedure for each type, and for each stack frame, that knows how to > find all the pointers. It could take the PC as a parameter, so it could > deal with optimizations where, for example, register R1 contains a > pointer sometimes, and an integer other times. We thought about this when we hacked the gcc backend to do accurate GC (see Diwan, Moss, Hudson PLDI '92.) Our feeling at the time was that the table size would be a lot smaller than the code size and the chances of being clever and reducing table size was high, we didn't have that confidence about the code route. In any case, if you count the 'out of cache' memory fetches, both code and data, the tables won since with tables your code is in the cache. > > >But in practice this seems to be limited by engineering considerations > >and table size. > > I agree. (Except I'd say engineering considerations and code size.) > > Another effect might be that in a GC'ed environment, an optimizer might > cause objects to be reachable for longer than they should be. > Alternatively, the compiler might try to insert "X := null" in order to > allow garbage to be collected earlier. Probably these are minor > effects, but there *is* some interaction between an optimizer and a > (nonconservative) gc. > > >It could require the existence of a collector, and a (partially) > >conservative collector may well be the most viable implementation > >strategy. > > Well, you can write "The implementation shall do garbage collection." in > a language definition, and this statement might have the desired effect > on compiler writers, but I don't know what it means in any *formal* > sense. > > Anyway, I don't understand why you would want a conservative collector, > unless you're dealing with an uncooperative language/compiler (like C). > If the language "requires" gc, then there's every opportunity to have a > well-defined interface between generated code and gc, so why be > conservative? Interoperability with C is the big win for conservative collectors. > > By the way, has anybody tried Boehm's conservative GC with GNAT? If it > works for gcc, it ought to work for GNAT, I would think. > > - Bob - Rick Hudson