Re: 'conservative' GC == 'risky' GC

pardo@cs.washington.edu (David Keppel) writes:
|> It's also worth noting that even with GC-safe code generation practices it
|> is still trivial to produce unsafe C programs -- the application can
|> obscure a pointer e.g. by XORing it, or can store it temporarily on disk
|> (outside of the default root set) and so on (but writing ANSI C is a good
|> start). The implication here is that only a subset of all C programs are
|> GC-safe and, in particular, you should be careful both about your code and
|> the code you link with.


ANSI C programs that do not use implementation dependent features can be
compiled to be safe in the presence of a conservative garbage collector.
In fact, even programs using the implementation dependent
pointer<->integer conversions of ANSI C could be compiled to be safe in
the presence of conservative GC. Basically, all the runtime would have to
do is to record those pointers that have been converted in this way and
exempt them from collection (but you need to deallocate them explicitly
after any such operation).


Of course, it would be preferable if facilities for garbage collection and
its interaction with language features like casts were actually defined in
the C/C++ language standards. The existence of conservative GC "add-ons"
to a wide variety of compilers demonstrates that this does not impose a
significant burden on language implementors.


Thomas.
[Isn't a strictly conforming program allowed to write a pointer to a file
and later read it back in? -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.