conservative GC (was Re: how to generate code for (a,b):=(b,a))

Dave Lloyd wrote:
>
> Oh no! C programs under Windows can, and indeed are recommended to,
> hide pointers to data structures in the operating system (this is
> bound with the window handle and is not visible in user address
> space). Indeed C programs can hide pointers anywhere and get away
> with it - I came across some code once that wrote blocks of memory
> holding pointers to disk and read them back in later (a simple manual
> VM subsequently abused to be a persistent store). You just can't do
> this in type secure programs, so no guarantees that you have all
> pointers and as we have also seen there are no guarantees that your
> pointers haven't been munged some way (another devious trick is to
> take advantage of 'spare bits' in the address space to blend in some
> flags with pointers).
>
> Conservative GCs are a good stopgap, but don't confuse them for the real
> thing with real security.


C is not a type-safe programming language. Without a garbage
collector, I can also arrange to overwrite malloc's data structures so
that a block appears to have been prematurely deallocated (or more
easily, so that the next call to malloc crashes). The fact that I can
break a C storage allocator is not interesting; the questions is
whether I can avoid doing so with a reasonable degree of caution.


Some of the things you mention above are violations of easily
expressible rules about programming with a garbage collector. Some of
them (spare bits in a pointer) are clear violations of the C standard.


Others (hiding pointers in the OS data structures) are things that a
conservative collector can and should deal with by intercepting the
appropriate calls. In this case, I believe the Geodesic Systems
collector does do so. (My freeware collector fails to address some of
these issues, largely due to its UN*X heritage.)


You could do none of these things if you used a conservative garbage
collector for Java, as many Java implementations do. There is of
course no real reason to use a fully conservative garbage collector
for Java. But there are good reasons to use partially conservative
collectors. (At the moment, our conservative collector appears to be
the fastest of the Java collectors I have access to. That is perhaps
a temporary aberation.)
--
Hans-Juergen Boehm
boehm@mti.sgi.com
--

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